But yes you are correct, removeAll results in a DELETE FROM [TABLE] WHERE ... so the delegator has no way of knowing what is being removed, this would effect the cache as well.
Regards Scott On 24/03/2010, at 5:58 PM, Scott Gray wrote: > The jira issue is talking about removeAll not storeAll > (https://issues.apache.org/jira/browse/OFBIZ-3554) > > Regards > Scott > > On 24/03/2010, at 5:51 PM, Wickersheimer Jeremy wrote: > >> I just know i ran into this problem, and i replaced storeAll by a loop which >> call store on >> each entity for it to work. >> You can look for the JIRA which has the exact code used. >> -- >> Wickersheimer Jeremy >> On Thursday 25 March 2010 07:38:19 Scott Gray wrote: >>> Hi Jeremy (is this your last name or first?) >>> >>> storeAll calls either store or create so doesn't that imply that it does >>> everything that they do? >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 24/03/2010, at 5:30 PM, Wickersheimer Jeremy wrote: >>>> Note that it seems delegator.storeAll does not trigger the EECAs, unlike >>>> delegator.store There a jira opened fir it but no patch atm. >>>> >>>>> Ruth Hoffman wrote: >>>>>> Hi BJ: >>>>>> Thanks. So does this mean that EECAs work as follows?: >>>>>> 1) A GenericDelegator object is gotten by the calling program >>>>>> 2) The GenericDelegator code looks to see if any EECAs are defined for >>>>>> the given Entity using the DelegatorEcaHandler >>>>>> 3) If any EECAs are defined for the Entity, those conditions are >>>>>> evaluated and any actions are run >>>>>> 4) Program control passes back to the GenericDelegator >>>>>> 4) The GenericDelegator does whatever it was called to do >>>>>> 5) Program control returns to the caller >>>>> >>>>> More complex. >>>>> >>>>> Before database save, after database save, before/after cache put, >>>>> before/after key looking, list lookup, etc. Lots of events are >>>>> watchable. >
smime.p7s
Description: S/MIME cryptographic signature
