>
> 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
>
>
