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
