jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Isolation level inconsistency.
Date Mon, 23 Jul 2007 19:25:25 GMT
IvanLatysh wrote:
>   But now query run against persistent state and return transient state, 
> that is totally confusing.

I agree with you that this not intuitive but returning a node with the 
persistent state is IMO worse.

Let say you have a node A. Then you set property p which gives you A' (the 
transiently modified A). Then you query the workspace for nodes with property p 
and the value you just set. The query would then return node A. Now you modify 
that very same node instance and set property q to another value. Will this 
result in A''? What happens to A'? What happens if you call refresh() on A'' 
will it also refresh A'? What will be persisted if you call Session.save(), A' 
or A'' or modifications from both? Assuming it were possible that you *can* save 
just A', does a save on A'' throw a InvalidItemStateException? If I had the time 
I could probably go one for minutes and write down more of those tricky questions.

However there is one thing I never really paid attention to so far: while the 
method QueryResult.getNodes() returns items that reflect the transient changes 
of the session, QueryResult.getRows() does not have to and probably should not 
reflect transient changes. I think the current spec does not really mention 
whether values of transient properties or persisted properties are returned. 
Since a JCR Row does not return JCR Items but only JCR Values which are not 
attached to Items the Row should return the values of the persistent properties. 
This is currently not the case in Jackrabbit. But as mentioned before it is not 
clearly specified.

regards
  marcel

Mime
View raw message