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.

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



Reply via email to