How often is "frequently"? If it is 1000/second, you have a problem, but you'd
have a problem with most solutions.
Measure or estimate how many documents are affected, how often. Then set a
latency for how long you can wait before the change is visible.
With those, you can evaluate solutions. W
You could use the same approach for users as for groups - have a {!join}
filter query to select docs that a user is allowed to see, and another
to select groups they are allowed to see.
I've no idea how performant this would be for you, as it depends on how
many documents a single user is allowed
Users also have rights at the individual level (in addition to
inheritance of their group), your solution implies that I attach
potentially 1million identifier in the document? I do not know Solr
limitations, but I think I approach it?
Le 21/03/2013 10:47, Upayavira a écrit :
You could attach
You could attach the doc rights to the document itself, and then index
the group rights into a separate core, and then use pseudo-joins to
filter them. Effectively, you would say, "find me all the groups that my
user is allowed to see, then find me all documents that are in those
groups, based upon
@Jan Høydahl : do you mean "cutom filter" ?
@Walter Underwood : I also agree with you, I'd only use native functions
of Solr, but I do not know how to solve my problem ... My ACLs are
composed of thousands of groups (inheritance) that have deny / allow
user rights and who themselves have deny /
I agree. Your first step should not be trying to make Solr work they way your
think it should. Try really hard to use the existing features, they are there
because they solve a LOT of problems.
Updates are pretty fast, really.
wunder
On Mar 20, 2013, at 2:36 AM, Jan Høydahl wrote:
> Don't try
If you implement filtering on both user and group levels. So you record on the
document ACL fields which group(s) it belongs to, and when people search you
find what groups they are entitled to see and add that as a filter. So if the
rights for a group changes, then you don't need to reindex the
Actually my goal is to integrate Zend Framework ACL in Solr. My problem
mainly concerns the inheritance, if rights of a group of documents are
changed, I can not go through all the documents for the group and update
these.
Don't try to optimize something which is not a problem.
This is what "everyone" does - update documents when ACLs for those documents
change, even with multi-million documents. It works like a charm. Or do you
have a special usecase where permissions for an average document changes
several time
Hello and thank you for your answers.
I'll try to explain my problem a little better:
The goal is to manage ACLs via Solr without reindex the documents at
each change of permission. I have hundreds of thousands of documents,
users and groups and permissions (allow / denied) or each of these
gr
The simple answer is no. But the real question is what you are trying to
accomplish. Lucene and Solr are built and optimized around the concept of a
Boolean Query with AND, OR, and NOT terms/clauses - that should be
sufficient to implement whatever it is that you are trying to implement. For
ex
Not to my knowledge. I guess the nearest might be regular expressions
but that would involve one character, rather than one bit per element,
so not nearly as efficient.
How many bits? Can you break them down into separate fields?
Upayavira
On Tue, Mar 19, 2013, at 02:30 PM, Christopher ARZUR wro
Christopher,
Would you mind if i ask you about a sample?
19.03.2013 19:31 пользователь "Christopher ARZUR" <
christopher.ar...@cognix-systems.com> написал:
> Hi,
>
> Does solr (4.1.0) supports /bitwise/ AND or /bitwise/ OR operator so that
> we can specify a field to be compared against an index
13 matches
Mail list logo
