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

Reply via email to