Couldn’t you just keep passing the wrapped query and searcher down to Weight.scorer()?
This would allow you to wait until the query is executed to do term collection. If you want to protect against creating and executing the query with different searchers, you would have to make the query factory (or constructor) only visible to the query parser or parser plugin? I might not have followed you, this discussing challenges my understanding of Lucene and SOLR. Darin > On Dec 5, 2014, at 12:47 PM, Roman Chyla <roman.ch...@gmail.com> wrote: > > 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> >>
