lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danil ŢORIN <torin...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 15 Apr 2010 14:11:21 GMT
Agree.

However I don't see how lucene could suddenly change that even a
conversion tool is impossible to create.
After all it's all about terms, positions and frequencies.

Yeah..some additions as payloads may appear, disappear, or evolve into
something new, but those are on user's side anyway.

Analyzers indeed are delicate problem so when StandardAnalyzer(which
probably 90% of users use) for same string generates different set of
terms.
But again it's user side problem.
Nothing stops him to rip StandrardAnalyzer from whatever version of
lucene, adapt it to newer indexing API, plug it in and continue.

I already use > 50% customized analyzers, my own query parser and so on.
I have junits for (hopefully) all cases I need to cover, so if new
Analyzer misbehaves, it's my responsability.

Danil.

On Thu, Apr 15, 2010 at 16:56, Grant Ingersoll <gsingers@apache.org> wrote:
> I do think major versions should be able to read the previous version index.  Still,
even being able to do that is no guarantee that it will produce correct results.  Likewise,
even having an upgrade tool is no guarantee that correct results will be produced.  So, my
take is that we strive for it, but we all have to realize, and document, that it might not
always be possible.  Let's just be practical and pragmatic.  Past history indicates we are
capable of, for the most part, reading the prev. version index and upgrading it.  If it can't
be done automatically, then we can consider a tool.  If the tool won't work, then we will
have to reindex.  It doesn't have to be an all or nothing decision made in the void.  We've
always been very practical here about making decisions on problems that are directly facing
us, so I would suggest we move forward with the new approach (which I agree makes more sense
and is pretty prevalent across a lot of projects) and we take this issue on a case-by-case
basis.
>
> -Grant
>
>
> On Apr 15, 2010, at 9:49 AM, Yonik Seeley wrote:
>
>> On Thu, Apr 15, 2010 at 9:39 AM, Earwin Burrfoot <earwin@gmail.com> wrote:
>>> On Thu, Apr 15, 2010 at 17:17, Yonik Seeley <yonik@lucidimagination.com>
wrote:
>>>> Seamless online upgrades have their place too... say you are upgrading
>>>> one server at a time in a cluster.
>>>
>>> Nothing here that can't be solved with an upgrade tool. Down one
>>> server, upgrade index, upgrade sofware, up.
>>
>> It's still harder.  Consider a common scenario where you have one
>> master and the index being replicated to multiple slaves.  One would
>> need to stop replication to an upgraded slave until the master is also
>> upgraded.  Some people can't even stop replication because they use
>> something like a SAN to share the index.
>>
>> I'm just pointing out that there is a lot of value for many people to
>> back compatible indexes... I'm not trying to make any points about
>> when that back combat should be broken.
>>
>> -Yonik
>> Apache Lucene Eurocon 2010
>> 18-21 May 2010 | Prague
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message