You are right, Ian,
This question deserves a new thread.
Currently I am drawing up an architecture for a file handling system for
e-government:
permissions are scattered up to:
- the citizen : one active file for a citizen (= folder, infoholder in
xml, attachments)
- the community : visibility and handling for the citizens of one community
- the regional authority : regional indicators
This worries me for it is a typical case where you would run into
scalability problems.
Think of 50 000 open applications via that system. With 10 documents per
application
you would have 500 000.
Is that a nogo for Sling? Would be a pity. I wanted to come up with an
elegant solution :-)
Jos
On 11/09/2010 09:22 AM, Ian Boston wrote:
Jos,
If by result you mean a search result, then thats a separate issue from the
dynamic ACL itself, and not the direct subject of this thread. When I said
performance I was referring to the atomic act of determining if the ACE was
active for any attempt to access an item, not just search results.
However,
thats the way jackrabbit works.
JCR searches are "compiled" into Lucene Queries that generate Lucene Hits where
the Lucene document contains a node ID, which is extracted in the normal manner from JCR
(IIRC). If the current user cant read the item, its discarded.
This is fine for dense searches where most items can be read by the user, but
problematic for sparse searches.
Its also problematic for sorts that can't be performed inside Lucene, as this
results in all the items being loaded into memory before searching.
One way to avoid sorts of this form is to ban "order by" clauses that reference
any items other than properties of the node found.
BTW, problematic == non scalable, vertically or horizontally.
Ian
