Fantastic, thanks for the help.
The actual case is a bit more complicated, the documents themselves
aren't the items which have the associated created_by/shared_with data
on them. They are children of those items, so every time one of the
parents changed I'd have to update the same data on all the children.
As one parent object can have many hundreds of child objects, that
would get to be a huge amount of updates.
It sounds like passing in the list of id's isn't too crazy, so I'll
carry on down these lines for now and do some performance testing
against a decent sized dataset.
Cheers again for the help!
On Tue, Aug 24, 2010 at 7:05 PM, Shay Banon
shay.banon@elasticsearch.com wrote:
The good news is that if you use filter (either constant_score wrapping a
query or terms filter) is that the same effectiveness of your caching of doc
ids, so you should get good performance, even with a large list.
Regarding the list below, you can index that information on the document
level. For example, add created_by, shared_with, status (public or not), and
so on. Then, you can use an "or" filter on them. Thats possible assuming
that those "..." don't hide many more complex restrictions
-shay.banon
On Tue, Aug 24, 2010 at 8:59 PM, Richard Livsey richard@livsey.org wrote:I wish it was simpler, but there's no real grouping of documents on a
per-user basis.
A user can see a document if any of the following are true (and a few
other conditions):
- they are an admin
- they created the document
- they are a member of the project the document belongs to
- the document is "shared" with them
- the document is public
- etc...
The query to generate this list of documents can be fairly hairy, so
we cache a list of document IDs on a per-user basis.
So when doing a full-text search I have the IDs to restrict against,
but unfortunately it could number in the hundreds.Thanks.
