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 > >
