Hi, On 7/20/07, IvanLatysh <[EMAIL PROTECTED]> wrote:
Can anybody find a real-life use-case where query run against persistent state but fetched object has transient state ?
I would turn your question around and ask for a real-life use case where you'd want to search for transient changes.
Jukka Zitting wrote: > This difference, and the > fact there are virtually no use cases where you'd want to search for > transient changes, Today I saw a message from Mark Waschkowski with a good use case.
You mean the one in this thread? It's more a sequence of events than a real use case. Who is the user and what's the reason she would want to do something like that? More specifically, is there a reason why someone could not do a save() before executing a query that targets the same content?
> coupled with the architectural goal of keeping > transient changes fully local (i.e. not involved in full text index > updates, etc.) makes IMHO a pretty good rationale for the way search > is specified in JCR. B.t.w. there are no need to do the full index update, search result always post-processed to account for the transient state, that how it usually done.
This is OK when you are handling "traditional" database rows that consist just of relatively small scalar values like integers or strings, but there's no way to efficiently query large binary properties without parsing and indexing the content. Full text search is an essential part of the JCR query features, and implementing it properly for transient changes *is* expensive. It's also something that many major pre-JCR content repositories explicitly don't do (i.e. they only index persisted changes).
P.S. Thank you for getting into the discussion.
You're welcome. It's an interesting subject, and I agree that the "query evaluated against persistent state, but results presented as transient nodes" mode of operation is confusing. BR, Jukka Zitting
