OK thanks Shai! Mike
On Mon, May 25, 2009 at 12:18 AM, Shai Erera <ser...@gmail.com> wrote: > 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
