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
