Part of these differences are handled by generating database specific scripts using Torque (but: only for Hsqldb, Oracle and MySql at the moment).
Even those generated scripts are not fail proof though. For Oracle, the generated drop table/create table sequences fail when a table doesn't exists yet. For first time usage on Oracle additional steps are required (see Known Issues for Oracle at: http://portals.apache.org/jetspeed-2/database.html).
Seeding scripts (right now default entities and userinfo data) used in the fullDeploy goal aren't even generated. Here we now use hand written scripts adapted to one or more databases (the latest addition: http://issues.apache.org/jira/browse/JS2-49).
I personally think this is going to get out of our hands. Now we are only dealing with Hsqldb, MySql and Oracle. When more databases are thrown into this mix I can only imagine how we are going to maintain all these differences.
If I need to change a create or seeding script for one database how can I do it for the others without being able to test it (I'm not going to install all databases to support this). Wait for others to fix resulting problems on their platform(s)? I don't like it possibly breaking a build/deploy just like that.
I don't know Torque very well so maybe all these differences can be factored out using the proper Torque scripts (even if we can't do that right now: see the initial Oracle installation problem as described above).
If Torque can generate different seeding scripts for each database maybe we should replace our current hard coded scripts with Torque scripts.
But, if Torque cannot handle this then what?
One option is continue like we do right now. Its not perfect, its likely going to result in (temporarily) broken build/deploy situations for different database users, but its what we have and its more or less workable.
Another option (and personally I think a better one) could be finding or building a proper database script or tool which can process or generated the needed sql (and maybe ddl, replacing the current Torque schema generation) based on database neutral definitions. A tool like DbUnit (LGPL) maybe can do things like that. Or, for seeding only, we can instantiate and fill in our own object model and persist that to the database using a groovy script (or whatever).
I think a good discussion and a clear decision would be wise because I expect the problems described above to become more and more a nuisance.
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
