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 roman.chyla@gmail.com
 designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANGii8fj0==_GmJrSDOfOyWsYqsaz6aURW5PkifpaLZbtJWBJw@mail.gmail.com>
References: <6C96541C-48BA-4B88-8326-E9687D965E6E@gmail.com>
 <CAEN8dyWhwXQeTer0WjQumfUJ6R_s=-Ha4GvHpYtPndans43T5g@mail.gmail.com>
 <CANGii8fj0==_GmJrSDOfOyWsYqsaz6aURW5PkifpaLZbtJWBJw@mail.gmail.com>
From: Roman Chyla <roman.chyla@gmail.com>
Date: Fri, 5 Dec 2014 12:47:42 -0500
Message-ID: 
 <CAEN8dyXqUXXXwXymDiHjE4jN24XN=Wa5WyJLQDBDZDpykHf2JA@mail.gmail.com>
Subject: Re: Anti-Pattern in lucent-join jar?
To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2f47aa3394905097badc3

--001a11c2f47aa3394905097badc3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mikhail, I think you are right, it won't be problem for SOLR, but it is
likely an antipattern inside a lucene component. Because custom components
may create join queries, hold to them and then execute much later against a
different searcher. One approach would be to postpone term collection until
the query actually runs, I looked far and wide for appropriate place, but
only found createWeight() - but at least it does give developers NO
opportunity to shoot their feet! ;-)

Since it may serve as an inspiration to someone, here is a link:
https://github.com/romanchyla/montysolr/blob/master-next/contrib/adsabs/src=
/java/org/apache/lucene/search/SecondOrderQuery.java#L101

roman

On Fri, Dec 5, 2014 at 4:52 AM, Mikhail Khludnev <mkhludnev@griddynamics.co=
m
> wrote:

> Thanks Roman! Let's expand it for the sake of completeness.
> Such issue is not possible in Solr, because caches are associated with th=
e
> searcher. While you follow this design (see Solr userCache), and don't
> update what's cached once, there is no chance to shoot the foot.
> There were few caches inside of Lucene (old FieldCache,
> CachingWrapperFilter, ExternalFileField, etc), but they are properly mapp=
ed
> onto segment keys, hence it exclude such leakage across different
> searchers.
>
> On Fri, Dec 5, 2014 at 6:43 AM, Roman Chyla <roman.chyla@gmail.com> wrote=
:
>
> > +1, additionally (as it follows from your observation) the query can ge=
t
> > out of sync with the index, if eg it was saved for later use and ran
> > against newly opened searcher
> >
> > Roman
> > On 4 Dec 2014 10:51, "Darin Amos" <darincs@gmail.com> wrote:
> >
> > > Hello All,
> > >
> > > I have been doing a lot of research in building some custom queries
> and I
> > > have been looking at the Lucene Join library as a reference. I notice=
d
> > > something that I believe could actually have a negative side effect.
> > >
> > > Specifically I was looking at the JoinUtil.createJoinQuery(=E2=80=A6)=
 method
> and
> > > within that method you see the following code:
> > >
> > >         TermsWithScoreCollector termsWithScoreCollector =3D
> > >             TermsWithScoreCollector.create(fromField,
> > > multipleValuesPerDocument, scoreMode);
> > >         fromSearcher.search(fromQuery, termsWithScoreCollector);
> > >
> > > As you can see, when the JoinQuery is being built, the code is
> executing
> > > the query that is wraps with it=E2=80=99s own collector to collect al=
l the
> > scores.
> > > If I were to write a query parser using this library (which someone h=
as
> > > done here), doesn=E2=80=99t this reduce the benefit of the SOLR query=
 cache?
> The
> > > wrapped query is being executing when the Join Query is being
> > constructed,
> > > not when it is executed.
> > >
> > > Thanks
> > >
> > > Darin
> > >
> >
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com>
> <mkhludnev@griddynamics.com>
>

--001a11c2f47aa3394905097badc3--