My suggestion would be to keep caching by path, but have a session flag to deactivate it if the client wants to. And maybe another flag to "always revalidate" and make the second round trip to the server to be sure the object ID hasn't changed. I know it's a non-solution but at least the choices are offered to the developer and we don't set things in stone :)
Florent On Tue, Nov 16, 2010 at 11:40 AM, Florian Müller <[email protected]> wrote: > The change token can only be used to detect changes within an object. The > problem here is that we are potentially dealing with two objects. The root > of the problem is that a path is not a stable key for an object. > > An object can be updated in the repository without our knowledge. The cache > would then return an outdated object and everybody should be prepared for > that. refresh() reloads the current state from the repository. That works > fine if the object is retrieved through getObject(). You can move the object > around, unfile it, put it in multiple folders and it still works. The object > id is unambiguous. > > The cache currently maps object paths to object ids. When you call > getObjectByPath() it will look up the id for this path and gets the object > from the cache. If you move the object to a different folder, > getObjectByPath() shouldn't find it anymore. The path of the object has > changed and the old path is now invalid. Note that the object hasn't changed > and therefore the change token hasn't either. > Since there is no notification from the repository, the path-to-id mapping > can't be corrected. The cache still thinks the object is accessible through > this path. So getObjectByPath() returns the object although it should throw > a CmisObjectNotFound exception. > > Let's assume we create a new object in the place where the old object was. > The new object can now be accessed with the old path. Since the outdated > path-to-id mapping is still in place, getObjectByPath() returns the old > object and not the new one -- which clearly wrong. > > The problem that we are facing here is that there is no reliable way to keep > the path-to-id mapping up-to-date. If we want to be correct, we would have > to ask the repository for the current id for the given path every time > getObjectByPath() is called (3) -- or not use the cache at all (2). > > > - Florian > > > > > On 16/11/2010 08:23, Jens Hübel wrote: >> >> Shouldn't the change token solve that? How do we deal with the change >> token for other objects that are in the local cache? Ignore? Check on each >> access? Configurable? >> >> Jens >> >> >> -----Original Message----- >> From: Florian Müller [mailto:[email protected]] >> Sent: Montag, 15. November 2010 21:17 >> To: [email protected] >> Subject: getObjectByPath cache problem >> >> Hi all, >> >> I had another look at [1]. Unfortunately, it's an unsolvable problem. >> I can think of three ways to cope with it: >> >> 1. We leave it like it is, although it is very, very confusing when you >> run into this situation. >> >> 2. We don't cache by path. How would that affect applications? >> >> 3. When getObjectByPath is called we fetch the object id from the >> repository and then get the object from the cache. >> In the worst case, we would have to hit the repository twice. >> >> >> Any opinions? >> >> - Florian >> >> >> [1] https://issues.apache.org/jira/browse/CMIS-260 > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
