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 <erickerick...@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 <erd...@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 > > >
