On May 23, 2004, at 3:07 PM, Ate Douma wrote:
The current codebase more is containing more and more database specific sql scripts because sql and ddl currently cannot be defined in a database neutral way.
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.
I don't think its out of hand. The scripts are mostly for test data that could go away in the future once we have a customizer, live portlet application deployer.
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.Yes, I just adjusted the script for MySQL and committed.
As long as we have committers testing on each platform, we should have it covered.
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).
These tools, in my experience, can also have errors, configuration complexities etc. You still need someone testing the scripts on all platforms.
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]
