Hello All!
I would like to bring up an issue with accessing JCR Nodes withing a Session.
[quote]
3.1.3.2 Transient Storage in the Session
Changes not yet saved or discarded are called pending changes. Pending changes
are immediately visible through the session that made them but are not visible
through other sessions accessing the same workspace.
[/quote]
According to the 3.1.3.2 "Pending changes are immediately visible through the
session that made them..."
No let's see how QueryResult will behave ?
[quote]
4.6.12 QueryResult
As mentioned, all queries are run against the persistent state of a workspace,
pending changes stored in the Session are not searched. However, when an item is
accessed from within a QueryResult object, the state of the item returned will
obey the same semantics as if it were retrieved using a normal Node.getNode or
Node.getProperty, in other words the item state will reflect any pending changes
currently stored in the session. As a result, it is possible that a property
returned as a match will not reflect the value that caused it to be a match
(i.e., its persistent state). Applications can clear the Session (either through
save or refresh(false)) before running a query in order to avoid such
discrepancies.
[/quote]
First of all it does not obey 3.1.3.2, for some unknown reason "... all queries
are run against the persistent state of a workspace ..."
It is very confusing and it is very hard to find the use case for it.
But to make things worse, results will not match the query itself ".. the item
state will reflect any pending changes currently stored in the session ..".
Here I can say that Query behavior are useless and have no real life use-case
that ever need such functionality.
=== Proposal ===========================================
4.6.12 QueryResult
QueryResults reflect any pending changes currently stored in the session.
========================================================
--
Ivan Latysh
[EMAIL PROTECTED]
