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 <mkhlud...@griddynamics.com > wrote: > Thanks Roman! Let's expand it for the sake of completeness. > Such issue is not possible in Solr, because caches are associated with the > 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 mapped > onto segment keys, hence it exclude such leakage across different > searchers. > > On Fri, Dec 5, 2014 at 6:43 AM, Roman Chyla <roman.ch...@gmail.com> wrote: > > > +1, additionally (as it follows from your observation) the query can get > > 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" <dari...@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 noticed > > > something that I believe could actually have a negative side effect. > > > > > > Specifically I was looking at the JoinUtil.createJoinQuery(…) method > and > > > within that method you see the following code: > > > > > > TermsWithScoreCollector termsWithScoreCollector = > > > 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’s own collector to collect all the > > scores. > > > If I were to write a query parser using this library (which someone has > > > done here), doesn’t 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> > <mkhlud...@griddynamics.com> >
