Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 87172 invoked from network); 23 Jul 2007 19:25:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jul 2007 19:25:51 -0000 Received: (qmail 87931 invoked by uid 500); 23 Jul 2007 19:25:51 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 87897 invoked by uid 500); 23 Jul 2007 19:25:51 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 87877 invoked by uid 99); 23 Jul 2007 19:25:51 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jul 2007 12:25:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of marcel.reutegger@gmx.net designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 23 Jul 2007 12:25:48 -0700 Received: (qmail invoked by alias); 23 Jul 2007 19:25:27 -0000 Received: from adsl-84-227-51-50.adslplus.ch (EHLO [10.0.1.199]) [84.227.51.50] by mail.gmx.net (mp036) with SMTP; 23 Jul 2007 21:25:27 +0200 X-Authenticated: #894343 X-Provags-ID: V01U2FsdGVkX1+zb+4p8kGzlxB/MPaf/Kp2cjAJaZvkZ/tVWr9mq6 3UmY4VZCCkMOkL Message-ID: <46A500A5.4090902@gmx.net> Date: Mon, 23 Jul 2007 21:25:25 +0200 From: Marcel Reutegger User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: users@jackrabbit.apache.org Subject: Re: Isolation level inconsistency. References: <469F8942.70403@yourmail.com> <1b0d43d00707220747h4f1b0631x8f9544f8c0c83d73@mail.gmail.com> <46A39841.9000204@yourmail.com> <46A39AE9.4000902@gmx.de> <46A41CEE.8090601@yourmail.com> In-Reply-To: <46A41CEE.8090601@yourmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org IvanLatysh wrote: > But now query run against persistent state and return transient state, > that is totally confusing. I agree with you that this not intuitive but returning a node with the persistent state is IMO worse. Let say you have a node A. Then you set property p which gives you A' (the transiently modified A). Then you query the workspace for nodes with property p and the value you just set. The query would then return node A. Now you modify that very same node instance and set property q to another value. Will this result in A''? What happens to A'? What happens if you call refresh() on A'' will it also refresh A'? What will be persisted if you call Session.save(), A' or A'' or modifications from both? Assuming it were possible that you *can* save just A', does a save on A'' throw a InvalidItemStateException? If I had the time I could probably go one for minutes and write down more of those tricky questions. However there is one thing I never really paid attention to so far: while the method QueryResult.getNodes() returns items that reflect the transient changes of the session, QueryResult.getRows() does not have to and probably should not reflect transient changes. I think the current spec does not really mention whether values of transient properties or persisted properties are returned. Since a JCR Row does not return JCR Items but only JCR Values which are not attached to Items the Row should return the values of the persistent properties. This is currently not the case in Jackrabbit. But as mentioned before it is not clearly specified. regards marcel