lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erdinc Yilmazel <erdincyilma...@gmail.com>
Subject Re: Different index per user
Date Mon, 19 Apr 2010 17:34:56 GMT
Thanks Erick,
I don't have any access control constraints. The index won't be exposed to
the users. I am just concerned about scalability issues. I'll probably use
adding a user identifier field approach first and I'll try sharding based on
that value when my index grows.

Erdinc

On Mon, Apr 19, 2010 at 1:22 AM, Erick Erickson <erickerickson@gmail.com>wrote:

> No really better ways that spring to mind. At root you have to somehow
> know what document is added by each user, and adding a field to
> the document with this info is quite reasonable, then just tack
> on an +user:<current user> to each query.
>
> You can get creative with Lucene Filters. That is, create a Filter for
> a user when s/he logs on pass that to queries, see some of the
> Searcher.search methods that take a Filter. But there's no
> real reason to go there unless you have performance problems.
>
> This is the fairly simple case, you're not indicating that you're after
> some generic Access Control List functionality so I'd stick with
> the simple approach until proven inadequate...
>
> HTH
> Erick
>
> On Sun, Apr 18, 2010 at 5:37 PM, Erdinc Yilmazel <erdinc@yilmazel.com
> >wrote:
>
> > I am building an online application where I want to provide search
> > functionality to users and each user is to search only within his own
> data.
> > Can you give me some ideas about the structure of the index that I should
> > have in this scenario? I know I could use a different index per user
> > account
> > but that is simply not practical. I could also create a single index and
> > use
> > a separate field to identify the documents that are related to a user
> > account and create my queries accordingly. However I am guessing that
> there
> > might be better ways to partition my index based on the user identifiers.
> >
> > Thanks,
> >
> > Erdinc
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message