|
»
»
»
« Return to Thread: nested predicate
Re: nested predicate
by Martin Zdila-3
::
Rate this Message:
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 [@gfr: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
> > [@gfr: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:m.zdila@...
> > http://www.mwaysolutions.com
> > xmpp:zdila@... (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:m.zdila@...
http://www.mwaysolutions.com
xmpp:zdila@... (Jabber)
skype:m.zdila
Thanks for your advices.
> Before going into detail how I would recommend you to attack your
> problem, first 1 question: what would this [@gfr: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
> > [@gfr: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:m.zdila@...
> > http://www.mwaysolutions.com
> > xmpp:zdila@... (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:m.zdila@...
http://www.mwaysolutions.com
xmpp:zdila@... (Jabber)
skype:m.zdila
« Return to Thread: nested predicate
| Free Forum Powered by Nabble | Forum Help |