Yes - 1630. I'll check 1601 and if nothing's left to do I'll cancel/close it
On Sun, May 24, 2009 at 11:25 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > Actually, under LUCENE-1601, what more was there to do besides turning > off scoring when sorting by field, by default? > > Is there an issue for adding & mating Scorer.scoresDocsInOrder & > Collector.acceptsDocsOutOfOrder? > > Mike > > On Sun, May 24, 2009 at 3:22 PM, Shai Erera <ser...@gmail.com> wrote: > > I created LUCENE-1601 for that purpose with a fix-version 3.0. I noticed > you > > already opened another issue for the scoring only. So we should remove it > > from there (note that there's a TODO in the code, if you plan to change > it > > in the new issue you opened). 1601 will still handle the new method added > to > > Searcher (and I think there were some other TODOs in the code too). > > > > On Sun, May 24, 2009 at 3:48 PM, Michael McCandless > > <luc...@mikemccandless.com> wrote: > >> > >> I'll open an issue for this and we can discuss under there. > >> > >> And I still need to open issues for the other "change defaluts" in my > >> original email. > >> > >> Mike > >> > >> On Sun, May 24, 2009 at 8:11 AM, Shai Erera <ser...@gmail.com> wrote: > >> >> I'm tempted to simply make that change by default for 2.9, now. > >> > > >> > Agree ! > >> > > >> > Shai > >> > > >> > On Sun, May 24, 2009 at 1:28 PM, Michael McCandless > >> > <luc...@mikemccandless.com> wrote: > >> >> > >> >> On Sun, May 24, 2009 at 2:20 AM, Shai Erera <ser...@gmail.com> > wrote: > >> >> > One thing I don't fully understand about actsAsVersion (and I know > it > >> >> > was > >> >> > said that we may want to drop that approach) - for how long does it > >> >> > stay? I > >> >> > mean, let's take the invalidAcronym. It is a change in back-compat, > >> >> > yes. > >> >> > But > >> >> > for how long are we expected to support it? And if we decide to > >> >> > support > >> >> > it > >> >> > for one minor release, or even one major release, will that ctor be > >> >> > deprecated? (I think it must be deprecated ...) > >> >> > >> >> Well, it's pretty clear actsAsVersion in any form (global static, > >> >> magically stored in index, passed in to ctors of those classes that > >> >> wanted to change settings) has too many objections, so this question > >> >> is somewhat moot. (Yet, if I had to guess, I think we'd want to > >> >> support it for longer than 1 minor release, especially for settings > >> >> that impact how your index is created). > >> >> > >> >> Forcing a decision on upgrading, by deprecating the old API, is I > >> >> think an adequate workaround in most cases. New users would not use > >> >> the deprecated API, and the javadocs would strongly call out which > >> >> default is preferred. Old users would see nothing change, except new > >> >> deprecations, and when they go to fix the deprecations they'd see > what > >> >> setting to use to remain back-compat, and also realize what they are > >> >> foregoing by doing so. > >> >> > >> >> > Also, Mike - you suggested coming up with newer names to methods to > >> >> > reflect > >> >> > new features (such as a boolean saying whether to score when you > >> >> > sort). > >> >> > This > >> >> > is strongly related to our ability to add methdods to > >> >> > interfaces/abstract > >> >> > classes. If we add an abstract method to Searcher with the new > >> >> > boolean, > >> >> > we're breaking back-compat. > >> >> > >> >> Right, though I think on a case by case basis we are in fact willing > >> >> to break this, because the back-compat policy is not set in stone. > EG > >> >> we've added new abstract methods to Searcher. > >> >> > >> >> Still, I think for 2.9 we have to migrate away from all interfaces. > >> >> EG we need a dedicated issue w/ migration patch, to move away from > >> >> Searchable. > >> >> > >> >> > Those specific problems (scoring when sorting) came into play only > >> >> > since > >> >> > the > >> >> > introducation of the "fast and easy" search methods (which if you > >> >> > look > >> >> > at > >> >> > their signature - they are not so fast and easy anymore). If we had > >> >> > just > >> >> > search(Collector, Query) (and maybe a couple other variants which > >> >> > need > >> >> > to > >> >> > take into account more than just Collector and Query) you won't > have > >> >> > that > >> >> > problem. > >> >> > >> >> But I think providing the sugar methods (that create TSDC or TFDC) is > >> >> important: > >> >> > >> >> search(Query query, int topN) > >> >> > >> >> search(Query query, int topN, Sort sort) > >> >> > >> >> Simple things should be simple; complex things should be possible. > >> >> > >> >> It's just that that 2nd method should by default do no scoring. > Maybe > >> >> we could simply consider changing that default (w/o adding the new > >> >> API) for 2.9? > >> >> > >> >> > A reviewer, or anyone else will be required to first create a > >> >> > Collector. > >> >> > They read somewhere that TFC is used for sorting and that it has a > >> >> > bunch > >> >> > of > >> >> > static create() methods. If they don't read it, they at least see a > >> >> > sample > >> >> > somewhere. So they create a TFC and maybe they see a couple of > >> >> > completions > >> >> > to create or not, but at least the changes are local to TFC. We can > >> >> > add > >> >> > more > >> >> > create() variants to TFC w/o breaking back-compat, because TFC is > not > >> >> > extandable. > >> >> > >> >> Sure, if we had no sugar methods then any wanting to do a search > would > >> >> be forced to be fully explicit. But the power of good defaults is > >> >> you're not forced to go and make a bunch of decisions on settings > that > >> >> have natural defaults. > >> >> > >> >> > Coosing the defaults of each create() is bound to whether we want > the > >> >> > defaults to always reflect the best usage (which I prefer). At > least > >> >> > in > >> >> > the > >> >> > scoring example, I was under the impression we keep scoring for the > >> >> > sake > >> >> > of > >> >> > back-compat, even if by changing it, it means nothing too bad will > >> >> > happen > >> >> > (we all kind of agree that scoring when sorting is useless, but > >> >> > because > >> >> > of > >> >> > our back-compat policy we can't change it). I think there Grant's > >> >> > proposal > >> >> > to decide on a case-by-case basis would have eliminated scoring > when > >> >> > sorting > >> >> > by default. > >> >> > >> >> Right, when sorting by field we should not score, by default. I'm > >> >> tempted to simply make that change by default for 2.9, now. When > >> >> compared to, say, changing IndexReader.open to return a readOnly > >> >> reader by default, which I think would mess up alot of apps, I think > >> >> not scoring by default when sorting by field will have much less of > an > >> >> impact. > >> >> > >> >> Mike > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> >> > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
