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
>
>