Question about EECAs
Locked
Question about EECAs
 
|
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
On 24/03/2010, at 5:24 PM, Adam Heath wrote:
> 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. Regards Scott |
smime.p7s (3K)
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
In reply to this post by Wickersheimer Jeremy
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. > > -- > Wickersheimer Jeremy > On Thursday 25 March 2010 07:24:06 Adam Heath wrote: >> 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. |
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
Re: Question about EECAs
|
|
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. |
Re: Question about EECAs
|
|
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. > |
Re: Question about EECAs
|
|
| Free forum by Nabble | Edit this page |