On 7/20/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
Alexandru Popescu ? wrote:
> I agree with both you comments here. However, I do feel that the OP
> may be right (I confess that I was not facing this situation so far,
> but this is probably because my app is a bit different).
>
> I would really appreciate if somebody would post on this thread a
> scenario in which the current behavior is proving helpful (and I have
> in mind the scenario posted here: searching for a John and getting a
> Joe instead -- frankly speaking I would be totally surprised in real
> life if I would be looking for my wife and getting somebody else
> instead :-) ).
I don't think the current JCR behavior was specced this way because
there are uses cases needing it. It's simply a result of queries working
against the persisted state (as the workspace methods), while the
regular read messages don't.
Agreed... and this probably the root cause that makes it look like an
implementation specific detail, and not as something generic enough.
I totally agree that this can cause surprising results, and the fix for
that is not to do it. That is, save the changes first, or query + read
using a separate session object. If this is not clear in the spec, let's
fix *that* first.
Yep. We should probably try to make it more strong in the spec and
provide this level of information in there. At least this will
guarantee that the spec offers the solution if this behavior
represents a problem to the users.
bests,
./alex
--
.w( the_mindstorm )p.
Best regards, Julian
