(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
