Marcel Reutegger wrote:
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.
If I understood you correctly:
1) query repository for node with property P=steve
2) got node A with property P=steve
3) set node A property P=john (making it transient)
4) query repository for node with property P=john
5) got node A (transient) with property P=john
6) set property Q=test
What you missed is that every time query will return the same transient state,
so no A' and A'' will ever exist, and node A persisted with all changes.
If query return persistent state only you will see a bit different behavior.
1) query repo for node with property P=steve
2) got node A with property P=steve
3) set node A property P=john (making it transient)
4) query repository for node with property P=john
5) got nothing
6) query repo for node with property P=steve
7) got node A' (since A is a transient at this moment) with property P=steve
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.
Thank you for pointing it out. It is one more reason to make sure that isolation
level *must* be defined in the spec and impl. should obey it.
--
Ivan Latysh
[EMAIL PROTECTED]
