Marcel Reutegger wrote:
Florent Guillaume wrote:
In JCR, there are *three* stages, the first stage being the transient
space.
1. The data you write is transient.
2. You save() the transient space and it becomes the equivalent
of "uncommitted" in a RDB, and is taken into account in
searches.
Or you can refresh() and all *or part of* your transient changes
are lost (you have granularity here).
jackrabbit does not take into account saved changes that are not yet
committed. after looking up the relevant spec section again, it seems to
me that the spec is not clear about this:
6.6.7 Search Scope
"A query searches the persistent workspace associated with the current
session. It does not search any pending changes that may be recorded on
the session but not yet saved."
The first sentence implies that you have to commit before you can search
your changes. the second sentence says that you cannot search transient
changes. it doesn't really say what happens with saved, yet uncommitted
changes.
"persistent workspace", in the absence of transactions, is whatever has
been saved. As transactions are not supposed to change the semantics,
but just provide a level of isolation/rollback with the rest of the
world, to me it still means "whatever has been saved" when transactions
are enabled.
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
