> > 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, resulting in node > A') > > 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 (the original from the store because A' is still > transient) > > with property P=steve > > > > And what Marcel was trying to say was: > > > > 8) set node A property Q=test (making it transient, resulting in node > A'' > > because it's not the same as the one in the store and also different > from > > A'? Or does something else happen?) > > 9) What happens when we call save() or refresh() on A' or A''? > > > refresh will do it's job per spec, no difference here.
but the spec doesn't cover the case when you have three instances of the same node: A, A' and A''. > Save will throw an exception when transient state has such conflict. how do you resolve such a situation? let's say theoretically you can refresh A' in order to save A'', how do you get to that node using a path or the UUID? e.g. if the node is referenceable and I call Session.getNodeByUUID() will the method return A' or A''? Returning transient nodes for QueryResult.getNodes() is the only reasonable option! However I agree with you that a JCR implementation should be allow to also consider transient changes when executing a query. regards marcel -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
