Jukka Zitting wrote:
On 7/20/07, IvanLatysh <[EMAIL PROTECTED]> wrote:
It is an outrageous bug in the spec, that has to be fixed [...]
I do appreciate your opinions and the fact that you are raising
issues, but the way you are presenting them is borderline trolling.
There are valid reasons for the design decisions taken by the JCR
spec, and while you are free to disagree and debate the rationale,
calling them "outrageous bugs" is IMHO rather extreme.
Yes it is, I absolutely agree with you that this expression is extreme, and it
serve it's purpose.
Can anybody find a real-life use-case where query run against persistent state
but fetched object has transient state ?
If your DB session would have such behavior would you be happy ?
Note that there's a crucial difference between JCR and DB sessions. In
relational databases search (i.e. SELECT) is the one and only way to
access content, whereas a content repository supports both direct API
access and search as ways to access content.
Personally I do not see the difference in accessing the date between
SQL QUERY/SP/VIEW and JCR QUERY/XPATH/API
But it doesn't even matter, let's take a Hibernate (ORM) for instance.
It has 2 ways of retrieving the data SQL and API. And Hibernate query always
return transient state of the object.
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.
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.
P.S. Thank you for getting into the discussion.
--
Ivan Latysh
[EMAIL PROTECTED]
