> 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.
>

This is the same semantic (i.e. remove a load of stuff :-) that we need to
improve to make <cascade-delete> efficient. I would be fairly easy to extend
that to user-defined operations.

I'm against adding delete (or insert and update) semantics to JBoss-QL
though - that changes the nature of the language from read-only to
read-write.

Instead you could define a DeleteMethod as:

  <deleter>
    <method-name>deleteByCode</method-name>
    <method-params>
        <method-param>int</method-param>
    <method-params>
    <jboss-ql>where code = ?1</jboss-ql>
  </deleter>

or, using values from the another entity via a subquery

  <deleter>
    <method-name>deleteByCode</method-name>
    <method-params>
        <method-param>int</method-param>
    <method-params>
    <jboss-ql>
      where code in
        (select x.code from another x where x.flag = ?1)
    </jboss-ql>
  </deleter>

This leaves the JBoss-QL part read-only (it just qualifies the instances to
be deleted). We know we're deleting Transactions as the method would be on
the home interface for the Transaction EJB.

It would be easy enough to extend this to bulk update as well - ok, easy if
you limited the update to single-valued fields.

Bulk create would be harder (need to pass in a lot of data), and probably
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

Reply via email to