In your case that client's key is fairly static, yes? It doesn't change at
any time, but tends to live on the data more or less permanently?
On Tue, Oct 18, 2016 at 4:07 PM, Markus Jelsma <markus.jel...@openindex.io>
> In case you're not up for Doug or Jan's anwers; we have relied on HTTP
> proxies (nginx) to solve the problem of restriction for over 6 years. Very
> easy if visibility is your only problem. Of course, the update handlers are
> hidden (we perform indexing for clients with crawlers) so we don't expose
> anything update related.
> For us, it's is just simple translating a client's key to a filter query
> There are many answers depending on what you need.
> -----Original message-----
> > From:John Bickerstaff <j...@johnbickerstaff.com>
> > Sent: Tuesday 18th October 2016 23:00
> > To: email@example.com
> > Subject: Public/Private data in Solr :: Metadata or ?
> > I have a question that I suspect I'll need to answer very soon in my
> > current position.
> > How (or is it even wise) to "segregate data" in Solr so that some data
> > be seen by some users and some data not be seen?
> > Taking the case of "public / private" as a (hopefully) simple, binary
> > example...
> > Let's imagine I have a data set that can be seen by a user. Some of that
> > data can be seen ONLY by the user (this would be the private data) and
> > of it can be seen by others (assume the user gave permission for this in
> > some way)
> > What is a best practice for handling this type of situation? I can see
> > putting metadata in Solr of course, but the instant I do that, I create
> > obligation to keep it updated (Document-level CRUD?) and I start using
> > more like a DB than a search engine.
> > (Assume the user can change this public/private setting on any one piece
> > "their" data at any time).
> > Of course, I can also see some kind of post-results massaging of data to
> > remove private data based on ID's which are stored in a database or
> > datastore...
> > How have others solved this and is there a consensus on whether to keep
> > out of Solr, or how best to handle it in Solr?
> > Are there clever implementations of "secondary" collections in Solr for
> > this purpose?
> > Any advice / hard-won experience is greatly appreciated...