jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Behaviour of Node.getPath()
Date Wed, 12 Mar 2008 16:40:30 GMT
>  >  the [1] is optional but addresses the same path.
>  >
>  >  i.e. /foo[1]/bar and /foo/bar address the same node no matter if the
>  >  /foo has same name siblings or not.
>  >
>
> Hi Toby,
>
>  As far as XPath per se is concerned, absolutely agree. However, the
>  index becomes significant when using XPath to search a repository e.g.
>  the queries "/jcr:root/foo/bar/element(*, my:type)" and
>  "/jcr:root/foo[1]/bar[1]/element(*, my:type)" aren't equivalent when
>  either foo or bar have same-name siblings. It would have been useful
>  if there was a method or switch available which would include all
>  indices in the path, but, as I say, it's easy to workaround so it's
>  not exactly a blocker.
>
>
>  >  in any case, it's better to avoid SNS if the data model allows this,
>  >  since they cause troubles in other places.
>  >  regards, toby
>  >
>
>
> Would you mind elaborating on what these problems are (before I start
>  to panic and rewrite our data model :-) ?
- first of all, the paths are not stable. eg. if you remove a same
name node all following node paths indexes change.
- the Node.getName() cannot be used to address the node since it does
not include the index.

there are certainly more i can't remember. but the first is the most
severe problem.
regards, toby

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message