Hi Julian, I've actually brought this issue up with the version 1.0 of the spec and found it confusing. Using
session.getRootNode().getNode(path) 'sees' any transient changes already, so there is already support for the transient changes within JCR and the session, albeit not using queries. Furthermore, SQL databases all see transient changes within the same transaction, so there is certainly precedent (and examples) for this type of behavior... Best, Mark On 7/19/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
IvanLatysh wrote: > Julian Reschke wrote: > >> again you're proposing a major change to JCR. > Sorry for my ignorance, but it is funny, you just dropped XPath and you > saying that fixing of an obvious mistake is a major change ? (1) I didn't drop, the EG basically proposes to drop it. It's under public review, right? That being said, I'm in favor of keeping XPath as mandatory. (2) I strongly disagree that the current property data model is a mistake; actually, I think it's the right design. >> If a query would need to take transient changes into account, it needs >> to operate both on the persisted state, and on the local transient >> space. Note that these may be on different machines. Maybe it's just >> me, but I have no idea how that could be implemented efficiently, *in >> particular* if you don't have the luxury to develop that functionality >> from scratch. > I am sorry, but an implementation of that is a trivial task, everybody > does it. > Have a look at any persistence engines. Well, you seem to be very sure, so I guess I won't argue with you and go back to my JCR 1.0 L2 implementation, which does not and will not work that way. Best regards, Julian
-- Best, Mark Waschkowski
