jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: difference between xpath searches
Date Wed, 27 Jun 2007 14:34:01 GMT

Thanks for the response Jukka.

I understand what you said, that JSR 170 considered it better to exclude
added nodes from the results. However, it really seems like a bad choice to
have the getNode(xpath) and the Query.execute() have different behaviors.
Hibernate, for example, supports criteria queries and HQL, but the
semantically similar query will always return the same results, as long as
executed within the same transaction. JSR 170 repositories may provides
completely different results depending on the context of the session,
depending on which of the node retrieval methods are done, even if the
*exact same* xpath is used.

Furthermore, why is the full text indexing mentioned as being potentially
expensive when using Query but not when using session.getRootNode

I'm interested to hear your response, and if you don't think I'm out in left
field here, I may attempt to provide some feedback to JSR 283 about this.



On 6/27/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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


Mark Waschkowski

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message