To clarify some points rised on the thread "Design change in Infinispan Query", which I don't wish to derail further:
The Query engine can actually apply per-entry user restriction access in an efficient way which doesn't involve (necessarily) to check each result; currently this needs specific user coding but: # it's not too hard as Hibernate Search users do it regularly: we provide various helpers and examples. Especially in the book :-) # is not including a pre-canned strategy as -at least in case of our Hibernate integration - the details of how people want it done are often exotic. Essentially a typical solution would work with Filters: a filter is a bitset which masks potential results from queries, so it's applied upfront actual scoring and other more complex match operations. These bitsets are very suited for filters, and are split on segments so that pre-computed segments related to parts of an index which didn't change can be reused even if the index as a whole is mutating continually. Such a Filter could even encode the response of some external authorization service on a per-document base (slow but effective), or it simply represents user group tokens which are applied as tags on the indexed documents (more efficient as long as role definitions are stable). That said, I'm not suggesting that this should be a priority, but I expect that sometime in the future we could provide a pre-canned strategy to work out of the box with our security extensions, at least for the benefit of remote protocols. So let's keep this in mind while making other design decisions. -- Sanne _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
