jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@onehippo.com>
Subject RE: nested predicate
Date Fri, 09 May 2008 12:20:39 GMT

> 
> As I need to implement the solution very quickly, I will 
> rather not experiment now and will implement it using my 
> "like" based solution. If it proves to be slow then I'll 
> switch it to your solution :-).

The "like" solution will most likely proof itself to be slow pretty soon
:-) 

> 
> Actually I don't understand much the difference between mine 
> and your method. 
> I thought Jackrabbit does the similar thing after parsing my 
> query - the ACL constraint will in any case end up in the 
> lucene. And also the query (filter) will be mostly the same 
> for the same user until he doesn't change roles.
> 
> I don't know Jackrabbit to Lucene internals yet so your 
> solution may be better if Jackrabbit creates more complicated 
> queries to Lucene from the XPath query.

In principal, if you are only using queries like @someprop=val, or
@ACL=someVal, the difference won't be that significant in speed (except
that mine would use a cached filter, where yours whould have AND-ed
lucene expressions all the time). OTOH, I was more referring to your
path constraint (/jcr:root/gfr:system/gfr:channels/gfr:channel) and the
"LIKE" construction. 

So, if you true to avoid the
/jcr:root/gfr:system/gfr:channels/gfr:channel and try to avoid the
"LIKE" construction, your solution quite likely only will be a little
slower. But, apart from performance POV, my solution IMO has a nicer
seperation of concerns, since....having to take ACLs into account in
each of your XPATH's....that doesn't look very nice to me. Typically, I
would use a cached filter for it, but of course, yo uare free of choice,
and as you mentioned, you're in a tight schedule :-)

-Ard

> 
>

Mime
View raw message