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