jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy T. Fielding <field...@gbiv.com>
Subject refresh method or version stamp
Date Sun, 17 Apr 2005 04:25:39 GMT
On Apr 16, 2005, at 4:41 PM, Daniel Dekany wrote:
> For example, the specification should introduce nt:monitored (don't 
> deal
> with the poor name choice for now...), that should mean that the node
> has these properties:
> - jcr:uuid
> - jcr:modificationCounter which is automatically created and 
> initialized to
>   0, and whose value is *automatically* incremented whenever a 
> property of
>   the node is written. Yeah, there are lot of unclear things about 
> this,
>   it was just a quick starting-point idea.
> This would be enough to implement a client side object cache 
> ("mapping")
> that I have talked about. If the uuid or modificationCounter of the 
> node
> returned for "foo/index" is changed, then the cached object shouldn't 
> be
> used. Furthermore I think that there should be a method in the JCR API
> for this check, so implementations can optimize this (IMO) frequent
> task.

Ah, okay, now i get it -- you want something equivalent to HTTP's
etag header field, and its corresponding If-match conditional methods.

Is there some reason why Item.refresh(false) does not do exactly
what you want, namely pick up any changes that have been persisted?

Note that the API does not need to reveal how it determined that
the node changed, so we don't even need a standard property name
like jcr:versionStamp (which is good since many systems will
already be storing internal version numbers per node).  The
implementation behind JCR can add whatever it needs to its own
node structures in order to make the check efficient.

This still doesn't have anything to do with ACID or ORM, so
that's why it was so hard to understand your concerns.


View raw message