Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of jlbetancourt@uci.cu
 designates 200.55.140.180 as permitted sender)
Date: Thu, 16 Jan 2014 09:13:11 -0500 (CST)
From: Jorge Luis Betancourt =?utf-8?Q?Gonz=C3=A1lez?= <jlbetancourt@uci.cu>
To: solr-user@lucene.apache.org
Message-ID: <1401432695.2324829.1389881591848.JavaMail.zimbra@uci.cu>
In-Reply-To: 
 <CALpnYG5QWU3fhN+SiiQAVFp+6zFVz_GYS2MiF4nfLsV+qHjmgg@mail.gmail.com>
References: 
 <CALpnYG5-=dmbEW-zf4V8yeEmnja_pOi4hHxh5HoUq5HyPZxufA@mail.gmail.com>
 <CAMJgJxR+00-P8zBDD46ki=WRV-CgfMOxkriTXKRtcKp7WtGcwg@mail.gmail.com>
 <CALpnYG5QWU3fhN+SiiQAVFp+6zFVz_GYS2MiF4nfLsV+qHjmgg@mail.gmail.com>
Subject: Re: Search Suggestion Filtering
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Search Suggestion Filtering
Thread-Index: 4AR88EG6rOwEeaRD7nnfNvppQdaVLw==

In a custom application we have, we use a separated core (under Solr 3.6.1)=
 to store the queries used by the users and then provide the autocomplete f=
eauture. In our case we need to filter some phrases, that we don't need to =
be suggested to the users. I build a custom UpdateRequestProcessor to imple=
ment this logic, so we define this "blocking patterns" in some external sou=
rce of information (DB, files, etc.). For the suggestions per-se we use as =
a base https://github.com/cominvent/autocomplete=E2=80=8E configuration, de=
scribed in www.cominvent.com/2012/01/25/super-flexible-autocomplete-with-so=
lr/=E2=80=8E which is pretty usable as it comes. I found (personally) this =
approach way more flexible than the original suggester component, but it in=
volves storing the user's queries into a separated core.

Greetings,

----- Original Message -----
From: "Hamish Campbell" <hamish.campbell@koordinates.com>
To: solr-user@lucene.apache.org
Sent: Wednesday, January 15, 2014 9:10:16 PM
Subject: Re: Search Suggestion Filtering

Thanks Tom=C3=A1s, I'll take a look.

Still interested to hear from anyone about using queries to populate the
list - I'm willing to give up a bit of performance for the flexibility it
would provide.


On Thu, Jan 16, 2014 at 1:06 PM, Tom=C3=A1s Fern=C3=A1ndez L=C3=B6bbe <
tomasflobbe@gmail.com> wrote:

> I think your use case is the one described in LUCENE-5350, maybe you want
> to take a look to the patch and comments there.
>
> Tom=C3=A1s
>
>
> On Wed, Jan 15, 2014 at 12:58 PM, Hamish Campbell <
> hamish.campbell@koordinates.com> wrote:
>
> > Hi all,
> >
> > I'm looking into options for filtering the search suggestions dictionar=
y.
> >
> > Using Solr 4.6.0, Suggester component and fst.FuzzyLookupFactory using =
a
> > field based dictionary, we're indexing records for a multi-tenanted Saa=
S
> > platform. SearchHandler records are always filtered by the particular
> > client warehouse (e.g. by domain), however we need a way to apply a
> similar
> > filter to the spell check dictionary to prevent leaking terms between
> > clients. In other words: when client A searches for a document title th=
ey
> > should not receive spelling suggestions for client B's document titles.
> >
> > This has been asked a couple of times, on the mailing list and on
> > StackOverflow. Some of the suggested approaches:
> >
> > 1. Use dynamic fields to create dictionaries per-warehouse (mentioned
> here:
> >
> >
> http://lucene.472066.n3.nabble.com/Filtering-down-terms-in-suggest-tt4069=
627.html
> > )
> >
> > That might be a reasonable option for us (we already considered a simil=
ar
> > approach), but at what point does this stop scaling efficiently? How ma=
ny
> > dynamic fields are too many?
> >
> > 2. Run a query to populate the suggestion list (also mentioned in that
> > thread)
> >
> > If I understand this correctly, this would give us a lot of flexibility
> and
> > power: for example to give a more nuanced result set using the users
> > permissions to expose private documents in their spelling suggestions.
> >
> > I expect this would be a slow query, but our total document count is
> > currently relatively small (on the order of 10^3 objects) and I imagine
> you
> > could create a specific word index with the appropriate fields to keep
> this
> > in check. Is this a feasible approach, and if so, how do you build a
> > dynamic suggestion list?
> >
> > 3. Other options:
> >
> > It seems like this is a common problem - and we could through some
> > resources at building an extension to provide some limited suggestion
> > dictionary filtering. Is anyone already doing something similar, or has
> > found a clever hack around this, or can suggest a starting point?
> >
> > Thanks everyone!
> >
> > --
> > Hamish Campbell
> > Koordinates Ltd <http://koordinates.com/?_bzhc=3Desig>
> > PH   +64 9 966 0433
> > FAX +64 9 966 0045
> >
>


--=20
Hamish Campbell
Koordinates Ltd <http://koordinates.com/?_bzhc=3Desig>
PH   +64 9 966 0433
FAX +64 9 966 0045
________________________________________________________________________________________________
III Escuela Internacional de Invierno en la UCI del 17 al 28 de febrero del 2014. Ver www.uci.cu