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