Your post once again shows that the DDL stuff is one of the most fragile parts of Nukes. It's obviously error-prone to keep the setup.xml (from which the setup.ddl seems to be generated via XSL; see nukes/nukes/src/resources/setup-xml2ddl.xsl) and the EJBs all sync'd up; and it's an unnecessary waste of precious time for the few core developers we users are all depending on. And it ignores one of the key strengths of the platform (j2ee/jboss) that brought us together here.
I stated my views on this in the thread:
but stopped pushing because I don't want to interfere with the 1.0 release.
But here's a new idea:
I'm willing to volunteer 20 hours (and maybe more) over the next week to help move Nukes away from this DDL mess prior to the 1.0 release. (There would be many advantages to releasing a clean Nukes that does all it's database setup thru CMP; see above thread for a list. IMHO, this 1 improvement could double the success of the Nukes 1.0 release, by making it far easier for people to get it going, on a wider variety of databases.)
If I were further along, I might be able to do the whole thing :), but I'm not -- i still haven't gotten an integrated Eclipse-JBossIDE-CVS-Nukes environment setup properly. I'm a newbie IRT contributing to the codebase, but I'm putting a few weeks full time on Nukes stuff starting this week, and want to help make Nukes a good solid platform we can all build on.
Maybe, if you're willing to work on it with me (I think your SQL expertise is stronger than mine), and we get guidance from Julien and a starter template from some of the JBoss CMP gurus, we could shift the whole DDL thing this week???
I'm willing to do much of the grunt work, if others who are more expert than I am give us a really good pattern to follow.
IMO, the work boils down to:
1) setting up the XDoclet tags for table create & destroy, identify primary key, to determine when indices are to be set up (Julien said that he uses index to "speed up queries and relationship traversal"), any constraints (Julien said none are used), etc...
2) translation of the SQL statements (considered as initialization specifications) into pure XML representations of the initialization data, and embedding the resultant XML fragment into the relevant setup.xml
3) from the proper place in the code (installer?), accessing the setup.xml, walking the XML subtree created in #2, extracting the data into data objects to use in initializing the EJBs, and making the EJB invocations to create & initialize the Entity EJBs (and thus persist the data into the tables).
Anything I've missed? (If others are interested, let's decompose these work items further in this thread. )
My strength would be more in #3, but if a JBossCMP guru did a good example for 2-3 entities that I could use as a pattern, then I could apply it to the other entities and handle the #1 & #3.
What do you think? How do you feel about #2?
I have removed all the .ddl files from the CVS, now they are all
generated through the XSL template.
At the same time I corrected the INSERT statements in hsqldb+mysql
Now that 1.0 is out, it's time for a genuine fix to this problem.