Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.132.248 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=rcm5kl/DinJi2AI/9KTApv/oTDz2sdoBikdwIDz4pv1L9FGvZjdg8BRjASK8+qmmwXaPeDwnpR9OIL3m8jSxzhHI3OY9IIUwl3lED4MHtUEKo+8XUpjHC1Q3RvZ9jYDgFVACOJCcTLD2js7zRrFiCMlbIr/yYKAqYXAXX8kIG28=
Message-ID: <510143ac0706270550v1ea38bd9l2d770743b722babc@mail.gmail.com>
Date: Wed, 27 Jun 2007 15:50:57 +0300
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: difference between xpath searches
In-Reply-To: <76a6ebd00706270540o2ceccd81p901f2a2972a605e9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <76a6ebd00706261121i90b040fiec371af4294b1112@mail.gmail.com>
	 <ae03024e0706262230t7688be0cm34f1b30219598200@mail.gmail.com>
	 <76a6ebd00706270540o2ceccd81p901f2a2972a605e9@mail.gmail.com>

Hi,

On 6/27/07, Mark Waschkowski <mwaschkowski@gmail.com> wrote:
> Regarding your last paragraph, 'potentially expensive operation' is the key
> part I believe. I still, unfortunately, am unsure of some of the details
> here and how they relate to the spec. First off, let me state that I think a
> query not seeing nodes that have been added within the current session is
> counter-intuitive because of how transaction contexts typically work within
> a database: if you insert a row into a table, but its not committed yet, you
> can still 'see' the new row from with your transactional context.

I agree that the behaviour seems strange if you come from a database
background, where search (the ubiquitous SELECT) is the one and only
way to access content. Typically content repository and JCR in
particular offer a set of content traversal methods (like
Node.getNode), which makes searching a more restricted use case. A
typical access pattern would be to search for content to update, not
to update content and then search for the changes.

Also, as Felix mentioned many content repositories (including
Jackrabbit) use full text indexing that makes index updates
potentially expensive. So, since there typically isn't a need to
search for unsaved changes, JSR 170 considered it better to exclude
transient changes from the search index.

BR,

Jukka Zitting