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/16 02:21:56 UTC
table rename idea
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
Re: table rename idea
Posted by Dave <sn...@gmail.com>.
+1
Those names are definitely better, and the schema is an important "first
place" that people look when they are trying to understand the code base.
- Dave
On Tue, Jul 15, 2014 at 8:21 PM, Glen Mazza <gl...@gmail.com> wrote:
> 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
>
>