Hello Ard Thanks for your advices.
> Before going into detail how I would recommend you to attack your > problem, first 1 question: what would this [EMAIL PROTECTED]:permission and 1 > = 1], > and then specifically 1 = 1 add in functionality? I actually meant [(@gfr:permission and 1) = 1] where "and" should do bitwise and ;-) But my first approach (bitwise-and-based) seems for me to be more unscaleable (although cleaner) as my second like-based. Do I understand you correctly that I would store ACLs to node properties as I do now and will use method described by you for querying? 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 :-). 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. One think which must also work - I am usin proprietary Jackrabbit's limit/offset functionality. I hope this will work with both solutions, just for sure :-). Thanks again for your time and valuable advices. I will also appreciate any further comments ;-). BR > Furthermore, I really think you're heading the wrong way: If you manage > to get your authorisation queries like you are describing below, to > work, I am quite confident that within short notice you'll end up having > incredible slow queries: I wouldn't be surprised if you're heading for > problems before you have 100.000 nodes in your repository (and with > //gfr:channel[jcr:like(gfr:aclEntry/@ace, 'g:user:%r%') your > application will be slow before you have 1.000 nodes in it) > > I really do recommend you to put some effort into a little extending > Jackrabbit, by overriding the SearchIndex and the NodeIndexer. Add your > own specific ACL properties logic into the lucene indexed properties > (use jackrabbit indexes, but add some indexed fields). After this, do > *not* think about how to construct xpath/sql queries with ACL logic: > just do the queries without ACL logic, but in your SearchIndex class, > add a filter to each search result from Jackrabbit, where the filter is > constructed by a ACL query for your current user. For one and the same > user, this filter is the same while none of the indexes changed, hence > really efficient cacheable (even if indexes change, you can even know > which bits to set to 0 in the filter). > > This is a scalable approach. One issue remains, and that is that you are > storing ACL information on nodes. IMHO, not the way to go, but perhaps > is suits your needs (though, I hope for you that the ACLs do not change > to often, making you have to set all ACLs over and over on all nodes) > > Hope this helps, > > Regards Ard > > > hello again > > > > it seems i must change my model for ACLs because even > > [EMAIL PROTECTED]:permission and 1 = 1] is illegal :-( > > > > my queries will look like > > > > //gfr:channel[jcr:like(gfr:aclEntry/@ace, 'g:user:%r%') or ...] > > > > in any case i appreciate any additional comments. > > > > cu > > -- > > Martin Zdila > > CTO > > > > M-Way Solutions Slovakia s.r.o. > > Letna 27, 040 01 Kosice > > Slovakia > > > > tel:+421-908-363-848 > > mailto:[EMAIL PROTECTED] > > http://www.mwaysolutions.com > > xmpp:[EMAIL PROTECTED] (Jabber) > > skype:m.zdila -- Martin Zdila CTO M-Way Solutions Slovakia s.r.o. Letna 27, 040 01 Kosice Slovakia tel:+421-908-363-848 mailto:[EMAIL PROTECTED] http://www.mwaysolutions.com xmpp:[EMAIL PROTECTED] (Jabber) skype:m.zdila
