#getSizeUnauthorized() would work for us, as we don't use authorisation through jackrabbit. (We use authentication, but we have to remove that as well, since it's not possible to change a username. Talk about optimising away features..)
On 25 July 2014 01:36, Ard Schrijvers <[email protected]> wrote: > On Thu, Jul 24, 2014 at 4:53 PM, Julian Reschke <[email protected]> wrote: >> On 2014-07-24 16:40, Thomas Mueller wrote: >>> >>> Hi, >>> >>> I believe the JCR API specification allows to return -1 in all cases. The >>> specification doesn't say -1 must not be returned if you use "order by". >>> If you relied on that, then you have relied on an implementation detail. >> >> >> Indeed. > > Well, if every Session.save() in oak would result in a > RepositoryException, then strictly speaking that would still be spec > compliant. So if my code relied on a Session.save() succeeding, did I > then rely on an implementation detail? > > Of course I am not too serious here, but I don't think it really helps > to refer to a specification in these cases and that someone relied on > an implementation detail. Don't we all? > >> >> >>>> Why I need to know the count is irrelevant. >>> >>> >>> Ehm, no, not to me. I'd like to understand the use case. > > I do understand the use case (we have it as well), but I also do > understand the enormous complexity of returning correct sizes. There > is a reason why Solr and Elastic Search do not have any support for > authorization. In the field of fine grained ACLs, which can change on > the fly, it is virtually impossible to index (adn to keep in sync) > ACLs in an inverted index, and thus, you have to do the authorization > after Lucene has returned the results. This however implies the > authorization typically has to fetch every JCR Node for every lucene > hit, and then do a isGranted check. If the number of hits is large, > and you run through your bundle caches (JR 2), it becomes really > expensive and slow to get an accurate #getSize. > > What we added locally was a #getTotalSize, or better, > #getUnauthorizedSize, which returns the size from lucene directly. > This already helped for quite some general use cases. A second thing > we added is an authorization query, where the security model we have > is mapped to a lucene query. However, this cannot be done generically > and only for domain specific implementation of access manager. > > Any way, hope this gives some feedback to Torgeir about the why and > the complexity. > > The use cases we face why we need a correct #getSize count is > typically because our customers want to see a correct number of pages > of hits. Also in the context of faceted navigation with counts, you > typically require counts that are correct. In the past years I > frequently tried to explain customers that , 'there are more than 100 > hits' would be good enough, but we faced the same request too often. > > Any way, long story short, I can imagine the default return size is -1 > in oak, it is spec compliant, and I do understand Torgeir would like > to get the behavior from JR 2 back in. Wouldn't be an option to expose > #getSizeUnauthorized() (and then of course a better name :-) > > Regards Ard > >> >> >> Absolutely. >> >> Best regards, Julian > > > > -- > Amsterdam - Oosteinde 11, 1017 WT Amsterdam > Boston - 1 Broadway, Cambridge, MA 02142 > > US +1 877 414 4776 (toll free) > Europe +31(0)20 522 4466 > www.onehippo.com -- -Tor
