Hi Jae,

Could you please go deeper into Nicholas' question, and clear something up for those 
of us who are curious...

Why is there any need for DDL at all?

Is the DDL, which was in the .ddl files and is now embedded in the  setup.xml files, a 
legacy of the database schema migration from the PHP Nukes model? 

Will it eventually be eliminated when Nukes takes full advantage of EJB2.0 CMP ??

Or, is there something that you guys have discovered that is outside what CMP can 
handle? ...that has to be done via a SQL/DDL approach? What are the particular 
database-specific issues that have to handled separately for each database?

What is the rationale for not using J2EE standard facilities to manage table creation 
(and possibly removal)? Why do we have these xdoclet tag values:
        
         * @jboss.persistence
         *    create-table="false"
         *    remove-table="false"
???

Why not go thru CMP to establish the DB? ....instead of .ddl, or embedded sql inside 
setup.xml, why not just have a utility to read nice clean XML (i.e., with no embedded 
SQL), and then go properly thru entity EJBs w CMP to create everything in the DB?

BTW,  a side effect of the above approach is that it would get us pretty far towards a 
powerful admin facility -- batch construction, under-the-hood maintenance, dump & 
reload of the entire Nukes database to pure XML... so IMHO, it would be a good way to 
go anyway. So why not initialize the system this way?

Perhaps this is the plan, and we're just not there yet? Or what am I missing?


View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3822232#3822232

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3822232


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to