The key is static indeed, just a subscription key. Under the hood it translates to a function query, which can vary. In our simple case it is really a key that translates to fq=host:(host1 host2 ... hostX). A simple backend sends this data to nginx every few minutes.
Again, just simple visibility. Nothing fancy. It works well for some cases. -----Original message----- > From:John Bickerstaff <j...@johnbickerstaff.com> > Sent: Wednesday 19th October 2016 0:10 > To: solr-user@lucene.apache.org > Subject: Re: Public/Private data in Solr :: Metadata or ? > > Thanks Markus, > > 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> > wrote: > > > 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 > > equivalent. > > > > There are many answers depending on what you need. > > > > M. > > > > > > > > -----Original message----- > > > From:John Bickerstaff <j...@johnbickerstaff.com> > > > Sent: Tuesday 18th October 2016 23:00 > > > To: solr-user@lucene.apache.org > > > 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 > > can > > > 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 > > some > > > 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 > > the > > > obligation to keep it updated (Document-level CRUD?) and I start using > > Solr > > > more like a DB than a search engine. > > > > > > (Assume the user can change this public/private setting on any one piece > > of > > > "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 > > similar > > > datastore... > > > > > > How have others solved this and is there a consensus on whether to keep > > it > > > 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... > > > > > >
