You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Glen Mazza <gl...@gmail.com> on 2014/07/20 05:28:46 UTC
DB change status
Hi Dave, ROL-2039 is finished. The database changes I'm (now) aware of
that we may wish to get done before we release 5.1:
1.) rename the "website" table to "weblog" (as its POJO is already
named). This should be a trivial change, as we already have a macro for
table renaming that we know works (it's in the 500-to-510 migration
script for the old webpage table.)
2.) In the interface TemplateRendition, to have a one-element
enumeration "VELOCITY" for the template language, just as I recently
added the RenditionType enum. As I've seen time and again with Roller
code, switching from string constants to enums does a very nice job of
tightening up the Java code and enhancing its readability. As part of
the migration from 5.0.x to 5.1.0, current instances of "velocity" will
need to be updated to "VELOCITY", a very trivial update statement in the
migration script. Switching to an enum though would have a drawback
though of Roller no longer able to accept other values besides VELOCITY
unless this enum is expanded due to the way JPA handles enums. (Perhaps
not such a big deal, as anyone hacking Roller to be able to process
another language can easily add that value to this enum anyway.)
3.) This could possibly wait until 5.1 is released, but we have no
referential integrity between WEBLOG_CUSTOM_TEMPLATE and
CUSTOM_TEMPLATE_RENDITION, also, our JPA is lacking the declared
one-to-many and many-to-one relationships between the two tables --
Roller just updates and deletes these two tables independently. As-is,
it's a little bit of a data model and a code smell.
If you want to take these over as part of other work you need to do,
you're most welcome, else I can work on them tomorrow.
I tested the 5.0.4 upgrade process on Derby at least (you'll be doing
MySQL as I understand) it seems to work fine except some app resource
constants were removed as a result of my cleaning up the app resource
files; namely, the button for edit may need to be updated to
"generic.edit" if it's using any of the older xxx.edit strings. (All
themes that Roller ships with have been updated, this is just for old
custom themes.) We can also return some of the strings to the app
resources files, but as lots of people have old string values I would
rather just make a comment in the release notes that some template
updates may be needed and keep our resources files to just what we need
today.
Regards,
Glen
Re: DB change status
Posted by Glen Mazza <gl...@gmail.com>.
(1) may actually be difficult to do for Derby, as I forgot that it
requires all FK constraints being dropped on the table being renamed:
rename table website to weblog;
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'WP_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 30000
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'WE_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'WC_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'FO_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'MF_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'NF_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
Error: Operation 'RENAME' cannot be performed on object
'SQL140718163851800' because CONSTRAINT 'AP_WEBSITEID_FK' is dependent
on that object.
SQLState: X0Y25
ErrorCode: 99999
It may be advisable to rename the table to "weblog" anyway but put the
rename command at the very top of the migration script. That way Derby
and MS-SQL Server folks will have the upgrade fail immediately, with the
understanding that manual operations will be needed to upgrade their
databases, while users of all other databases can upgrade normally.
This only effects Derby users upgrading from 5.0.x to 5.1, new Derby
users starting from 5.1 won't have this problem as they will be using
"Weblog" with the new script from Day #1.
Or we can shelve this until later. I just put in a JIRA request to
Derby to support table renames such as the above
(https://issues.apache.org/jira/browse/DERBY-6672), but they have over
1100 open issues, but we may get lucky. :)
Glen
On 07/20/2014 08:36 AM, Glen Mazza wrote:
> (2) is done.
>
> Glen
>
> On 07/20/2014 07:42 AM, Glen Mazza wrote:
>> I'm taking care of (2) below right now, I missed a couple of areas
>> yesterday and am making (2) part of that cleanup. Should be checked
>> in soon...
>>
>> Glen
>>
>> On 07/19/2014 11:28 PM, Glen Mazza wrote:
>>> Hi Dave, ROL-2039 is finished. The database changes I'm (now) aware
>>> of that we may wish to get done before we release 5.1:
>>>
>>> 1.) rename the "website" table to "weblog" (as its POJO is already
>>> named). This should be a trivial change, as we already have a macro
>>> for table renaming that we know works (it's in the 500-to-510
>>> migration script for the old webpage table.)
>>>
>>> 2.) In the interface TemplateRendition, to have a one-element
>>> enumeration "VELOCITY" for the template language, just as I recently
>>> added the RenditionType enum. As I've seen time and again with
>>> Roller code, switching from string constants to enums does a very
>>> nice job of tightening up the Java code and enhancing its
>>> readability. As part of the migration from 5.0.x to 5.1.0, current
>>> instances of "velocity" will need to be updated to "VELOCITY", a
>>> very trivial update statement in the migration script. Switching to
>>> an enum though would have a drawback though of Roller no longer able
>>> to accept other values besides VELOCITY unless this enum is expanded
>>> due to the way JPA handles enums. (Perhaps not such a big deal, as
>>> anyone hacking Roller to be able to process another language can
>>> easily add that value to this enum anyway.)
>>>
>>> 3.) This could possibly wait until 5.1 is released, but we have no
>>> referential integrity between WEBLOG_CUSTOM_TEMPLATE and
>>> CUSTOM_TEMPLATE_RENDITION, also, our JPA is lacking the declared
>>> one-to-many and many-to-one relationships between the two tables --
>>> Roller just updates and deletes these two tables independently.
>>> As-is, it's a little bit of a data model and a code smell.
>>>
>>> If you want to take these over as part of other work you need to do,
>>> you're most welcome, else I can work on them tomorrow.
>>>
>>> I tested the 5.0.4 upgrade process on Derby at least (you'll be
>>> doing MySQL as I understand) it seems to work fine except some app
>>> resource constants were removed as a result of my cleaning up the
>>> app resource files; namely, the button for edit may need to be
>>> updated to "generic.edit" if it's using any of the older xxx.edit
>>> strings. (All themes that Roller ships with have been updated, this
>>> is just for old custom themes.) We can also return some of the
>>> strings to the app resources files, but as lots of people have old
>>> string values I would rather just make a comment in the release
>>> notes that some template updates may be needed and keep our
>>> resources files to just what we need today.
>>>
>>> Regards,
>>> Glen
>>>
>>
>
Re: DB change status
Posted by Glen Mazza <gl...@gmail.com>.
(2) is done.
Glen
On 07/20/2014 07:42 AM, Glen Mazza wrote:
> I'm taking care of (2) below right now, I missed a couple of areas
> yesterday and am making (2) part of that cleanup. Should be checked
> in soon...
>
> Glen
>
> On 07/19/2014 11:28 PM, Glen Mazza wrote:
>> Hi Dave, ROL-2039 is finished. The database changes I'm (now) aware
>> of that we may wish to get done before we release 5.1:
>>
>> 1.) rename the "website" table to "weblog" (as its POJO is already
>> named). This should be a trivial change, as we already have a macro
>> for table renaming that we know works (it's in the 500-to-510
>> migration script for the old webpage table.)
>>
>> 2.) In the interface TemplateRendition, to have a one-element
>> enumeration "VELOCITY" for the template language, just as I recently
>> added the RenditionType enum. As I've seen time and again with
>> Roller code, switching from string constants to enums does a very
>> nice job of tightening up the Java code and enhancing its
>> readability. As part of the migration from 5.0.x to 5.1.0, current
>> instances of "velocity" will need to be updated to "VELOCITY", a very
>> trivial update statement in the migration script. Switching to an
>> enum though would have a drawback though of Roller no longer able to
>> accept other values besides VELOCITY unless this enum is expanded due
>> to the way JPA handles enums. (Perhaps not such a big deal, as anyone
>> hacking Roller to be able to process another language can easily add
>> that value to this enum anyway.)
>>
>> 3.) This could possibly wait until 5.1 is released, but we have no
>> referential integrity between WEBLOG_CUSTOM_TEMPLATE and
>> CUSTOM_TEMPLATE_RENDITION, also, our JPA is lacking the declared
>> one-to-many and many-to-one relationships between the two tables --
>> Roller just updates and deletes these two tables independently.
>> As-is, it's a little bit of a data model and a code smell.
>>
>> If you want to take these over as part of other work you need to do,
>> you're most welcome, else I can work on them tomorrow.
>>
>> I tested the 5.0.4 upgrade process on Derby at least (you'll be doing
>> MySQL as I understand) it seems to work fine except some app resource
>> constants were removed as a result of my cleaning up the app resource
>> files; namely, the button for edit may need to be updated to
>> "generic.edit" if it's using any of the older xxx.edit strings. (All
>> themes that Roller ships with have been updated, this is just for old
>> custom themes.) We can also return some of the strings to the app
>> resources files, but as lots of people have old string values I would
>> rather just make a comment in the release notes that some template
>> updates may be needed and keep our resources files to just what we
>> need today.
>>
>> Regards,
>> Glen
>>
>
Re: DB change status
Posted by Glen Mazza <gl...@gmail.com>.
I'm taking care of (2) below right now, I missed a couple of areas
yesterday and am making (2) part of that cleanup. Should be checked in
soon...
Glen
On 07/19/2014 11:28 PM, Glen Mazza wrote:
> Hi Dave, ROL-2039 is finished. The database changes I'm (now) aware
> of that we may wish to get done before we release 5.1:
>
> 1.) rename the "website" table to "weblog" (as its POJO is already
> named). This should be a trivial change, as we already have a macro
> for table renaming that we know works (it's in the 500-to-510
> migration script for the old webpage table.)
>
> 2.) In the interface TemplateRendition, to have a one-element
> enumeration "VELOCITY" for the template language, just as I recently
> added the RenditionType enum. As I've seen time and again with Roller
> code, switching from string constants to enums does a very nice job of
> tightening up the Java code and enhancing its readability. As part of
> the migration from 5.0.x to 5.1.0, current instances of "velocity"
> will need to be updated to "VELOCITY", a very trivial update statement
> in the migration script. Switching to an enum though would have a
> drawback though of Roller no longer able to accept other values
> besides VELOCITY unless this enum is expanded due to the way JPA
> handles enums. (Perhaps not such a big deal, as anyone hacking Roller
> to be able to process another language can easily add that value to
> this enum anyway.)
>
> 3.) This could possibly wait until 5.1 is released, but we have no
> referential integrity between WEBLOG_CUSTOM_TEMPLATE and
> CUSTOM_TEMPLATE_RENDITION, also, our JPA is lacking the declared
> one-to-many and many-to-one relationships between the two tables --
> Roller just updates and deletes these two tables independently. As-is,
> it's a little bit of a data model and a code smell.
>
> If you want to take these over as part of other work you need to do,
> you're most welcome, else I can work on them tomorrow.
>
> I tested the 5.0.4 upgrade process on Derby at least (you'll be doing
> MySQL as I understand) it seems to work fine except some app resource
> constants were removed as a result of my cleaning up the app resource
> files; namely, the button for edit may need to be updated to
> "generic.edit" if it's using any of the older xxx.edit strings. (All
> themes that Roller ships with have been updated, this is just for old
> custom themes.) We can also return some of the strings to the app
> resources files, but as lots of people have old string values I would
> rather just make a comment in the release notes that some template
> updates may be needed and keep our resources files to just what we
> need today.
>
> Regards,
> Glen
>