> Shawn wrote: > > One question if I may ask at the risk of sounding naive, > > In cases where the databases don't support > foreign keys (such as mysql), would it be useless to try and create them manually >in the > DbForms config file? > Not at all! Eric's new stylesheets will use that information to generate more sophisticated JSPs containing automatically generated selects etc. Even if the dbms does not support the foreign key feature, the references are part of the logical database schema.
> I need that functionality but suspect I may have to change databases or wait and see >how much > mySql 4 handles foreign keys. > Btw. MySQL-Max with InnoDB tables has support for foreign key constraints. I think there are still some limitations, but 'no support at all' is not true any more. > In any case, instead of writing all my own inteceptors, I'm hoping to pitch in and >get > DbForms able to handle foreign keys. Just to make clear: The first support for foreign keys within dbforms will not contain the ondelete/onupdate rules support. We will have a syntax for expressing foreign key constraints within config file, we will read that information at application startup time (so having it available within running application). And the xsl stylesheets will generate more sophisticated JSPs. Application development will be easier and faster but dbforms will not check the rules if someone ignores them within his application. Currently we think we should omit the onDelete/onUpdate usage within config file. It will irritate people because they expect something, but dbforms simply ignores it. Support for 'restrict' variants would be the most easiest rule to implement: If we have a A <---- B on delete restrict on update restrict we must just: - whenever we insert or update a B we just check if there is a referenced row in A if not, we generate an error - whenever we delete or update an A, we must check, if it was referenced by a B. If yes, we generate an error It is just a boolean function (allow or not) without any side effects. So something like onDelete="restrict" onUpdate="restrict" might be possible to implement in next version. But in case of 'cascade' rule we would have to generate cascading new events for the other tables. And without transaction support from the dbms we will not be able to do that: If we already have automatically deleted hundreds of rows and then get an error because of a missing grant or fired interceptor, we should rollback everything we have done so far. Nothing for a quickshot. And btw. I also think this should be done by the dbms, not the application. So to check the rules, you will propably still need to write interceptors for those dbms that do not support references. However, having the references information within metadata available, it might be possible to write an 'one interceptor for all' .... Regards Dirk ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
