lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <dmsmith...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Wed, 14 Apr 2010 14:39:48 GMT
On 04/14/2010 09:13 AM, Robert Muir wrote:
> Its not sidetracked at all. there seem to be more compelling 
> alternatives to achieve the same thing, so we should consider 
> alternative solutions, too.
Maybe have the index store the version(s) and use that when constructing 
a reader or writer?
Given enough minor releases, it is likely that different analyzers would 
use different versions. So each feature would need to be represented.

>
> On Wed, Apr 14, 2010 at 8:54 AM, Earwin Burrfoot <earwin@gmail.com 
> <mailto:earwin@gmail.com>> wrote:
>
>     The thread somehow got sidetracked. So, let's get this carriage back
>     on its rails?
>
>     Let me remind - we have an API on hands that is mandatory and tends to
>     be cumbersome.
>     Proposed solution does indeed have ultrascary word "static" in it. But
>     if you brace yourself and look closer - the use of said static is
>     opt-in and heavily guarded.
>     So even a long-standing hater of everything static like me is tempted.
>
>
>     On Wed, Apr 14, 2010 at 16:30, Grant Ingersoll
>     <gsingers@apache.org <mailto:gsingers@apache.org>> wrote:
>     >
>     > On Apr 14, 2010, at 12:49 AM, Robert Muir wrote:
>     >
>     >>
>     >> On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey
>     <marvin@rectangular.com <mailto:marvin@rectangular.com>> wrote:
>     >> New class names would work, too.
>     >>
>     >> I only mention that for the sake of completeness, though --
>     it's not a
>     >> suggestion.
>     >>
>     >> Right, to me this is just as bad.
>     >> In my eyes, the Version thing really shows the problem with the
>     analysis stuff:
>     >> * Used by QueryParsers, etc at search and index time, with no
>     real clean way to do back-compat
>     >> * Concepts like Version and class-naming push some of the
>     burden to the user: users decide the back-compat level, but it
>     still leaves devs with back-compat management hassle.
>     >>
>     >> The idea of having a real versioned-module is the same as
>     Version and class-naming, except it both pushes the burden to the
>     user in a more natural way (people are used to versioned jar files
>     and things like that... not Version constants), and it relieves
>     devs of the back compat
>     >>
>     >> In all honesty with the current scheme, release schedules of
>     Lucene, and Lucene's policy, the analysis stuff will soon deadlock
>     into being nearly unmaintainable, and to many users, the API is
>     already unconsumable: its difficult to write reusable analyzers
>     due to historical relics in the API, methods are named
>     inappropriately, e.g. Tokenizer.reset(Reader) and
>     TokenStream.reset(), they don't understand Version, and probably a
>     few other things I am forgetting that are basically impossible to
>     fix right now with the current state of affairs.
>     >
>     >
>     > The thing I keep going back to is that somehow Lucene has
>     managed for years (and I mean lots of years) w/o stuff like
>     Version and all this massive back compatibility checking.  I'm
>     still undecided as to whether that is a good thing or not.  I also
>     am not sure whether it in the past we just missed/ignored more
>     back compatibility issues or whether now we are creating more back
>     compat. issues due to more rapid change.  I agree, though, that
>     all of this stuff is making it harder and harder to develop (and I
>     don't mean for us committers, I mean for end consumers.)
>     >
>     > I also agree about Robert's point about the incorrectness of
>     naming something 3.0 versus 3.1 when 3.1 is the thing that has all
>     the new features and is really the "major" release.
>     >
>     > -Grant
>     >
>     ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     > For additional commands, e-mail: java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>     >
>     >
>
>
>
>     --
>     Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com
>     <mailto:earwin@gmail.com>)
>     Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>     ICQ: 104465785
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>     <mailto:java-dev-unsubscribe@lucene.apache.org>
>     For additional commands, e-mail: java-dev-help@lucene.apache.org
>     <mailto:java-dev-help@lucene.apache.org>
>
>
>
>
> -- 
> Robert Muir
> rcmuir@gmail.com <mailto:rcmuir@gmail.com>


Mime
View raw message