You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <Al...@Sun.COM> on 2005/12/20 19:34:48 UTC

db scripts

I think there are still a number of improvements that need to be made to the db scripts process, so i've outlined a few concerns/ideas ...

1. I don't like that we set the list of template files to be processed in each control file individually.  This is redundant and error prone because it's possible that someone could forget to add a new template for a given database.  Shouldn't that be kept in a master file that applies to all control files?

2. Same as above, I don't like that we include that foreach loop at the bottom of each control file.  I also think this should be in a more centralized master control file.

3. I also don't like that we have a macro definition in the 200-210 migration script.  I think the macros should once again be part of the master control file.  Then if a specific migration script really needs to override the default version of a macro then it can do so.

So putting that all together I am thinking we should modify the approach so that the script generation process is started by some master control file.  In that file we set the list of templates to process, a list of various macro definitions, and then put a loop that iterates through each control file and processes each template file for that control.

Also, what happened to all the old db scripts?  Are we not planning to include them in releases after Roller 2.0?

-- Allen



Re: db scripts

Posted by Dave Johnson <da...@rollerweblogger.org>.
Thanks for the review.


On Dec 20, 2005, at 1:34 PM, Allen Gilliland wrote:
> I think there are still a number of improvements that need to be made 
> to the db scripts process, so i've outlined a few concerns/ideas ...
> 1. I don't like that we set the list of template files to be processed 
> in each control file individually.  This is redundant and error prone 
> because it's possible that someone could forget to add a new template 
> for a given database.  Shouldn't that be kept in a master file that 
> applies to all control files?
> 2. Same as above, I don't like that we include that foreach loop at 
> the bottom of each control file.  I also think this should be in a 
> more centralized master control file.

Both good ideas.


> 3. I also don't like that we have a macro definition in the 200-210 
> migration script.  I think the macros should once again be part of the 
> master control file.  Then if a specific migration script really needs 
> to override the default version of a macro then it can do so.

Yes. The migration script is the wrong place. I'm still working on 
getting that macro right. It's working on MySQL and HSQLDB, now I to 
try the others.


> So putting that all together I am thinking we should modify the 
> approach so that the script generation process is started by some 
> master control file.  In that file we set the list of templates to 
> process, a list of various macro definitions, and then put a loop that 
> iterates through each control file and processes each template file 
> for that control.

Yeah. I like that idea too.

> Also, what happened to all the old db scripts?  Are we not planning to 
> include them in releases after Roller 2.0?

No need to keep generating those. I'll check them in under 
web/WEB-INF/dbscripts.

- Dave


Re: db scripts

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Dec 21, 2005, at 2:47 PM, Allen Gilliland wrote:
> On Wed, 2005-12-21 at 06:50, Dave Johnson wrote:
>> Done. We now have a properties file for each database (again), a 
>> master
>> control template and the addColumnNotNull() macro is defined 
>> centrally.
>>
>
> i don't understand exactly what happened here.  did you not commit 
> part of this?  because my build fails.

Oops. I forgot to commit the most important part. Done.


> also, i'm not sure we needed to go back to properties files, i think 
> the values in the properties files still need to be velocity variables 
> right?

I think I did the best I could without extending the Texen task, but I 
could be wrong. Yes, Texen puts the properties into the Velocity 
context.

- Dave


Re: db scripts

Posted by Allen Gilliland <Al...@Sun.COM>.
On Wed, 2005-12-21 at 06:50, Dave Johnson wrote:
> 
> Done. We now have a properties file for each database (again), a master 
> control template and the addColumnNotNull() macro is defined centrally.
> 

i don't understand exactly what happened here.  did you not commit part of this?  because my build fails.

also, i'm not sure we needed to go back to properties files, i think the values in the properties files still need to be velocity variables right?

-- Allen


> - Dave
> 


Re: db scripts

Posted by Dave Johnson <da...@rollerweblogger.org>.
On Dec 20, 2005, at 1:34 PM, Allen Gilliland wrote:
> 1. I don't like that we set the list of template files to be processed 
> in each control file individually.  This is redundant and error prone 
> because it's possible that someone could forget to add a new template 
> for a given database.  Shouldn't that be kept in a master file that 
> applies to all control files?
> 2. Same as above, I don't like that we include that foreach loop at 
> the bottom of each control file.  I also think this should be in a 
> more centralized master control file.
> 3. I also don't like that we have a macro definition in the 200-210 
> migration script.  I think the macros should once again be part of the 
> master control file.  Then if a specific migration script really needs 
> to override the default version of a macro then it can do so.
> So putting that all together I am thinking we should modify the 
> approach so that the script generation process is started by some 
> master control file.  In that file we set the list of templates to 
> process, a list of various macro definitions, and then put a loop that 
> iterates through each control file and processes each template file 
> for that control.

Done. We now have a properties file for each database (again), a master 
control template and the addColumnNotNull() macro is defined centrally.

- Dave