On Wed, Mar 12, 2008 at 5:40 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > > > > 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 :-) ?
have you read david's "data modeling rules" (http://wiki.apache.org/jackrabbit/DavidsModel)? you might find some useful hints/recommendations, see e.g. rule #4. > - 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's a Node#getIndex() method for that very reason ;) cheers stefan > > there are certainly more i can't remember. but the first is the most > severe problem. > regards, toby > > > > -- > -----------------------------------------< [EMAIL PROTECTED] >--- > 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 >--- >
