Hi Team, I don't know if I'll get to it, but I'm thinking of changing
the names of two tables (and their corresponding POJOs) prior to 5.1
going out to better clarify their purpose. I put in a new macro in our
database creation scripts allowing us to rename a table. It will work
for all databases except Microsoft SQL Server (which doesn't have a
rename table command OOTB, you have to call some stored procedure for
it) and in a few cases Derby, namely if another table references the
table you are renaming via a foreign key (not relevant in my situation
below), you have to drop the fk in Derby before renaming the table (and
recreating the fk).
The two tables are WEBPAGE and ROLLER_TEMPLATECODE. The webpage table
is populated only when a user decides to do modifications to one of the
standard themes, if that happens one row will be entered for the
stylesheet and one row for each of the templates making up the theme
into that table. In turn, for each of the rows added to WEBPAGE, one
(for "standard", for all single themes) or two rows ("mobile" and
"standard", if the basic-mobile dual theme is chosen) will be added to
ROLLER_TEMPLATECODE. Each row in the latter table stores the template
or stylesheet code that has been customized by the user. While there is
no formal defined database foreign key relationship, nonetheless the
latter table points back to the former via the "templateid" column.
I'm thinking of renaming WEBPAGE to CUSTOM_TEMPLATE and
ROLLER_TEMPLATECODE to CUSTOM_TEMPLATE_RENDITION. The WEBPAGE table
does not store webpages but just custom templates for a blog. Renaming
the latter to CUSTOM_TEMPLATE_RENDITION better shows the close
relationship between the two tables, and also better clarifies what the
latter is for: to store potentially multiple renderings of a custom
template -- standard, mobile, perhaps tablet for some people. WDYT?
Regards,
Glen
- table rename idea Glen Mazza
-
