jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jcr:deref in predicate
Date Fri, 24 Apr 2009 07:27:47 GMT
Hi,

On Wed, Apr 22, 2009 at 21:57, Dan Diephouse
<dan.diephouse@mulesource.com> wrote:
> Does RelationQueryNode have to be API compatible with 1.5?

it is a public class in spi-commons, which means it should be
compatible with 1.5. I don't know how many projects out there depend
on that class...

> Wondering if I
> have some freedom here. Otherwise it's going to end up a big ugly it looks
> like...

as an alternative we could try to add a new class, which leaves
RelationQueryNode untouched. but on the other hand that will introduce
a new method in QueryNodeVisitor. so we're back to square one.

I guess, no matter what we do there's always a chance that existing
code will break.

regards
 marcel

> 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