Jacques Le Roux wrote: > From: "Adrian Crum" <adrian.c...@sandglass-software.com> >> I don't understand what you mean when you say >> "entitycache.entity-list.default.PartyNameView nor >> entitycache.object-list.default.PartyNameView are not parts of >> utilCacheTable." Both of those caches extend >> AbstractEntityConditionCache, and that cache checks for view entities >> that the GenericValue is a member of. There is a chance there is a flaw >> in the view entity checking logic. > > Yes that's what I think also. I will have a deeper look when I will get a > chance > > Jacques
OK, my answer was not clear. What I meant is we try to clear the caches of entitycache.entity-list.default.PartyNameView and entitycache.object-list.default.PartyNameView using the content of utilCacheTable which contains only entitycache.entity.default.PartyNameView. So we don't find them and don't clear what we should (I guess entitycache.entity.default.PartyNameView) That's why I agree it's a flaw in the view entity checking cache logic regarding cache clearing. I'm looking at it... Jacques >> -Adrian >> >> On 5/12/2013 10:30 PM, Jacques Le Roux wrote: >>> I had a quick look. As reported in the Jira this is an old neglected or >>> unknown issue (reproductible in R11.04 and R12.04) >>> >>> In this peculiar case, when storing we clear the cache for 2 entities: >>> Person and Party. >>> We use an EntityView in the display-entity (PartyNameView) and clearing >>> the entity cache does not refresh the EntityView >>> cache. In other words, the cache clearing done by >>> this.clearCacheLine(value) in GenericDelegator.store() does not propagated >>> to >>> the EntityView cache. This is simply because >>> entitycache.entity-list.default.PartyNameView nor >>> entitycache.object-list.default.PartyNameView are not parts of >>> utilCacheTable. I noticed tough that >>> entitycache.entity.default.PartyNameView is. I stopped there... >>> >>> Note that the the >>> this.distributedCacheClear.distributedClearCacheLine(value) is >>> automatically done in >>> GenericDelegator.clearCacheLine(). >>> >>> HTH >>> >>> Jacques >>> >>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>> I fixed the entity condition cache. The cache being used in OFBIZ-5192 >>>> is the primary key cache. So that is the one to look at. >>>> >>>> Most likely, the code that saves the changes to Person is not clearing >>>> the pk cache - so that's why you see the stale data after an update. >>>> >>>> The entity model overhaul has nothing to do with this problem. >>>> >>>> -Adrian >>>> >>>> On 5/11/2013 11:32 AM, Jacques Le Roux wrote: >>>>> Ha, I thought you had already fixed the underneath issue. Now I remember >>>>> you also warned us at >>>>> https://issues.apache.org/jira/browse/OFBIZ-5146 and DCC will still to be >>>>> done >>>>> >>>>> OK, though it's not a biggie (not caching here does not hurt), I will >>>>> revert >>>>> >>>>> Note that I don't agree with >>>>>>>> Anyway, this should >>>>>>>> not be a problem on the trunk. >>>>> As I said it's easy to reproduce on trunk demo >>>>> >>>>> To be sure to understand. When your entity model overhaul WIP will be >>>>> committed this will fix this (kinda?) issue(s?) ? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>> You believe wrong. >>>>>> >>>>>> Please revert the OFBIZ-5192 related commits, then spend some time >>>>>> reviewing the discussion with the subject: "Important: Entity list cache >>>>>> and GenericValue discussion". >>>>>> >>>>>> Understand the problem before you try to fix it. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 5/11/2013 11:02 AM, Jacques Le Roux wrote: >>>>>>> I intially reproduced with trunk demo, so I fixed it there and >>>>>>> backported. >>>>>>> I believe it's unrelated to the issues you fixed >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>>> Oops, I didn't notice this was on a release branch. Anyway, this should >>>>>>>> not be a problem on the trunk. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 5/11/2013 10:14 AM, Adrian Crum wrote: >>>>>>>>> Are you sure this change is necessary? I fixed the caching problem a >>>>>>>>> few days ago. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/11/2013 10:09 AM, jler...@apache.org wrote: >>>>>>>>>> Author: jleroux >>>>>>>>>> Date: Sat May 11 09:09:26 2013 >>>>>>>>>> New Revision: 1481276 >>>>>>>>>> >>>>>>>>>> URL: http://svn.apache.org/r1481276 >>>>>>>>>> Log: >>>>>>>>>> "Applied fix from trunk for revision: 1481274" >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> r1481274 | jleroux | 2013-05-11 10:52:25 +0200 (sam., 11 mai 2013) | >>>>>>>>>> 14 lines >>>>>>>>>> >>>>>>>>>> Fix "Name in List Related Contacts form doesn't get updated" reported >>>>>>>>>> by Karl Beecher at https://issues.apache.org/jira/browse/OFBIZ-5192 >>>>>>>>>> >>>>>>>>>> If a person is set as a related contact for a party, updates to their >>>>>>>>>> name are not immediately displayed by the ListRelatedContacts form. >>>>>>>>>> >>>>>>>>>> To reproduce (with OFBiz demo data): >>>>>>>>>> * In the Party Manager, go to the profile page of DemoSupplier (they >>>>>>>>>> have a related contact called 'Peter Manager' >>>>>>>>>> * Follow the link to Peter Manager's profile page. >>>>>>>>>> * Click Update and change the name (e.g. to 'Peter Manageress') >>>>>>>>>> * Save >>>>>>>>>> * Return to DemoSupplier's profile page. Observe that the name of the >>>>>>>>>> related contact is still 'Peter Manager'. Refreshing doesn't change >>>>>>>>>> that. >>>>>>>>>> * Restart OFBiz >>>>>>>>>> * Refreshing the profile page now displays the updated name. >>>>>>>>>> >>>>>>>>>> jleroux: to test in trunk I used company and scrum employee >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/branches/release12.04/ (props changed) >>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>> >>>>>>>>>> Propchange: ofbiz/branches/release12.04/ >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> Merged /ofbiz/trunk:r1470176,1481274 >>>>>>>>>> >>>>>>>>>> Modified: >>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>> URL: >>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml?rev=1481276&r1=1481275&r2=1481276&view=diff >>>>>>>>>> ============================================================================== >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>> (original) >>>>>>>>>> +++ >>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>> Sat May 11 09:09:26 2013 >>>>>>>>>> @@ -771,7 +771,7 @@ under the License. >>>>>>>>>> <form name="ListRelatedContacts" type="list" >>>>>>>>>> list-name="contacts" default-table-style="basic-table"> >>>>>>>>>> <field name="partyIdTo"> >>>>>>>>>> - <display-entity entity-name="PartyNameView" >>>>>>>>>> description="${firstName} ${middleName} ${lastName} ${groupName}" >>>>>>>>>> key-field-name="partyId"> >>>>>>>>>> + <display-entity entity-name="PartyNameView" >>>>>>>>>> description="${firstName} ${middleName} ${lastName} ${groupName}" >>>>>>>>>> key-field-name="partyId" cache="false"> >>>>>>>>>> <sub-hyperlink description="[${partyIdTo}]" >>>>>>>>>> target="viewprofile"> >>>>>>>>>> <parameter param-name="partyId" >>>>>>>>>> from-field="partyIdTo"/> >>>>>>>>>> </sub-hyperlink>
