Jeremy, as I remember, once we already considered delete and update operations in JBossQL. This is great because we don't depend on the specific database. I thought this was planned for 4.0.
alex Friday, January 17, 2003, 7:08:43 PM, you wrote: >> I was thinking about something while looking at my application's >> database behaviour... in many cases it is very inefficient to use a >> finder method together with remove() for large collections. It would be >> so much more efficient to have something like >> >> public int deleteByCode(int code); >> >> <deleter> >> <method-name>deleteByCode</method-name> >> <method-params> >> <method-param>int</method-param> >> <method-params> >> <delete-method> >> <ejb-ql>delete from Transactions t where t.code = ?1</ejb-ql> >> </delete-method> >> </deleter> >> >> This all of course integrated with the cache so that it invalidates >> objects that are already loaded, etc. >> JB> This is the same semantic (i.e. remove a load of stuff :-) that we need to JB> improve to make <cascade-delete> efficient. I would be fairly easy to extend JB> that to user-defined operations. JB> I'm against adding delete (or insert and update) semantics to JBoss-QL JB> though - that changes the nature of the language from read-only to JB> read-write. JB> Instead you could define a DeleteMethod as: JB> <deleter> JB> <method-name>deleteByCode</method-name> JB> <method-params> JB> <method-param>int</method-param> JB> <method-params> JB> <jboss-ql>where code = ?1</jboss-ql> JB> </deleter> JB> or, using values from the another entity via a subquery JB> <deleter> JB> <method-name>deleteByCode</method-name> JB> <method-params> JB> <method-param>int</method-param> JB> <method-params> JB> <jboss-ql> JB> where code in JB> (select x.code from another x where x.flag = ?1) JB> </jboss-ql> JB> </deleter> JB> This leaves the JBoss-QL part read-only (it just qualifies the instances to JB> be deleted). We know we're deleting Transactions as the method would be on JB> the home interface for the Transaction EJB. JB> It would be easy enough to extend this to bulk update as well - ok, easy if JB> you limited the update to single-valued fields. JB> Bulk create would be harder (need to pass in a lot of data), and probably JB> unnecessary given we plan to have batch insert anyway. ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
