nested predicate

[Martin Zdila-3]

hello

i am storing ACL entries to JCR and i need to create query that returns all permitted nodes:

/jcr:root/gfr:system/gfr:channels/gfr:channel
[
        gfr:acl/gfr:aclEntries/gfr:aclEntry[@gfr:permission and 1 = 1]/element(gfr:sid, gfr:PrincipalSid)/@gfr:principal = 'martin' or
        gfr:acl/gfr:aclEntries/gfr:aclEntry[@gfr:permission and 1 = 1]/element(gfr:sid, gfr:GrantedAuthoritySid)/@gfr:grantedAuthority = 'ROLE_ADMIN' or
        gfr:acl/gfr:aclEntries/gfr:aclEntry[@gfr:permission and 1 = 1]/element(gfr:sid, gfr:GrantedAuthoritySid)/@gfr:grantedAuthority = 'ROLE_USER'
]

unfortunately i am getting javax.jcr.query.InvalidQueryException: Unsupported location for predicate

is there something wrong with my query? doesn't jackrabbit support nested predicates?
any idea how to rewrite my query to get expected result?

my node structure is:

+ gfr:channels
  + gfr:channel // multiple times
    + gfr:acl
      + gfr:aclEntries
        + gfr:aclEntry // multiple times
          - gfr:permission (long) // permissions as bit array
          + gfr:sid (nodeType = gfr:PrincipalSid or gfr:GrantedAuthoritySid)
            - @gfr:principal or @gfr:grantedAuthority // name of the SID
        + gfr:aclEntry ...
  + gfr:channel ...

thanks in advance.
--
Martin Zdila
CTO

M-Way Solutions Slovakia s.r.o.
Letna 27, 040 01 Kosice
Slovakia

tel:[phone]
mailto:m.zdila@...
http://www.mwaysolutions.com
xmpp:zdila@... (Jabber)
skype:m.zdila

[Martin Zdila-3]

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:[phone]
mailto:m.zdila@...
http://www.mwaysolutions.com
xmpp:zdila@... (Jabber)
skype:m.zdila

[Ard Schrijvers-3]

Hello Martin,

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?

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:[phone]
> mailto:m.zdila@...
> http://www.mwaysolutions.com
> xmpp:zdila@... (Jabber)
> skype:m.zdila
>

[Martin Zdila-3]

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:[phone]
> > 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:[phone]
mailto:m.zdila@...
http://www.mwaysolutions.com
xmpp:zdila@... (Jabber)
skype:m.zdila

[Ard Schrijvers-3]

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

>
>