jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: jcr:deref in predicate
Date Wed, 22 Apr 2009 19:57:44 GMT
Does RelationQueryNode have to be API compatible with 1.5? Wondering if I
have some freedom here. Otherwise it's going to end up a big ugly it looks
like...

On Wed, Apr 22, 2009 at 4:23 AM, Marcel Reutegger
<marcel.reutegger@gmx.net>wrote:

> Hi,
>
> On Mon, Apr 20, 2009 at 22:01, Dan Diephouse
> <dan.diephouse@mulesource.com> wrote:
> > I'm looking into this now and have a question. In a non predicate query I
> > see that Jackrabbit creates a DerefQueryNode and adds it to the
> > PathQueryNode via addPathSetp.
> > However, if one is working on a RelationQueryNode there is only the
> ability
> > to add Path.Elements. Am I correct in understanding that
> RelationQueryNode
> > may have to undergo some modifications here so it handle more than just
> > foo/bar/@blah type paths?
>
> yes, I think that's a reasonable approach.
>
> > Any suggestions on how this should look? Should RelationQueryNode maybe
> have
> > a PathQueryNode whose results get evaluated against the operand/value
> > instead of a series of Path.Elements?
>
> I'm not sure about all the details, but I guess that should work. I'd
> use keep the current
> methods and use a PathQueryNode internally for RelationQueryNode#relPath.
> then
> add new methods, i.e.
>
> - addPathStep(LocationStepQueryNode) -> works similar to
> addPathElement() but allows
> you to also add a DerefQueryNode
> - getRelativePathNode() -> works similar to getRelativePath() but
> returns the internal PathQueryNode
>
> just brain storming... might be missing something
>
> regards
>  marcel
>
> > (Does that even make sense? I still don't have a firm grasp of the query
> > mechanisms)
> >
> > On Fri, Apr 17, 2009 at 5:51 PM, Dan Diephouse
> > <dan.diephouse@mulesource.com> wrote:
> >>
> >> Yeah, it basically allows you to do joins of certain sorts when
> searching
> >> for items, which is *immensely* useful. I've got this coded up as two
> >> separate queries right now, but it's pretty slow and I can see how for
> some
> >> open queries it'd cause things to grind to a halt...
> >> Anyway, thanks for the feedback. I'll take a peek in the next couple
> days.
> >> Dan
> >>
> >> On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger
> >> <marcel.reutegger@gmx.net> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Apr 16, 2009 at 21:40, Dan Diephouse
> >>> <dan.diephouse@mulesource.com> wrote:
> >>> > I was contemplating implementing support for jcr:deref in xpath
> >>> > predicates a
> >>> > la https://issues.apache.org/jira/browse/JCR-977.
> >>> > There is a message from Mercel saying that the spec doesn't
> explicitly
> >>> > support this[1]. However it doesn't explicitly disallow it either...
> >>> > What is
> >>> > the feeling on Jackrabbit supporting it if I implement it?
> >>>
> >>> I think that would be a nice addition. I'd be very happy to review it
> >>> and provide feedback.
> >>>
> >>> > PS Still working on cleaning up my other patch for parent axis
> >>> > searching in
> >>> > axis predicates.
> >>>
> >>> cool. let us know if you need any help.
> >>>
> >>> regards
> >>>  marcel
> >>>
> >>> > 1.
> http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html
> >>> >
> >>> > --
> >>> > Dan Diephouse
> >>> > http://mulesource.com | http://netzooid.com/blog
> >>> >
> >>
> >>
> >>
> >> --
> >> Dan Diephouse
> >> http://mulesource.com | http://netzooid.com/blog
> >
> >
> >
> > --
> > Dan Diephouse
> > http://mulesource.com | http://netzooid.com/blog
> >
>



-- 
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

Mime
View raw message