lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
Subject Re: Proposal about Version API "relaxation"
Date Thu, 15 Apr 2010 12:42:37 GMT
I like the idea of index conversion tool over silent online upgrade
because it is
1. controllable - with online upgrade you never know for sure when
your index is completely upgraded, even optimize() won't help here, as
it is a noop for already-optimized indexes
2. way easier to write - as flex shows, index format changes are
accompanied by API changes. Here you don't have to emulate new APIs
over old structures (can be impossible for some cases?), you only have
to, well, convert.

On Thu, Apr 15, 2010 at 16:32, Danil ŢORIN <torindan@gmail.com> wrote:
> All I ask is a way to migrate existing indexes to newer format.
>
>
> On Thu, Apr 15, 2010 at 15:21, Robert Muir <rcmuir@gmail.com> wrote:
>>
>> its open source, if you feel this way, you can put the work to add
>> features to some version branch from trunk in a backwards compatible way.
>> Then this branch can have a backwards-compatible minor release with new
>> features, but nothing ground-breaking.
>> but this kinda stuff shouldnt hinder development on trunk.
>>
>> On Thu, Apr 15, 2010 at 8:17 AM, Danil ŢORIN <torindan@gmail.com> wrote:
>>>
>>> Sometimes it's REALLY impossible to reindex, or has absolutely
>>> prohibitive cost to do in a running production system (i can't shut it down
>>> for maintainance, so i need a lot of hardware to reindex ~5 billion
>>> documents, i have no idea what are the costs to retrieve that data all over
>>> again, but i estimate it to be quite a lot)
>>> And providing a way to migrate existing indexes to new lucene is crucial
>>> from my point of view.
>>> I don't care what this way is: calling optimize() with newer lucene or
>>> running some tool that takes 5 days, it's ok with me.
>>> Just don't put me through full reindexing as I really don't have all that
>>> data anymore.
>>> It's not my data, i just receive it from clients, and provide a search
>>> interface.
>>> It took years to build those indexes, rebuilding is not an option, and
>>> staying with old lucene forever just sucks.
>>>
>>> Danil.
>>> On Thu, Apr 15, 2010 at 14:57, Robert Muir <rcmuir@gmail.com> wrote:
>>>>
>>>>
>>>> On Thu, Apr 15, 2010 at 7:52 AM, Shai Erera <serera@gmail.com> wrote:
>>>>>
>>>>> Well ... I must say that I completely disagree w/ dropping index
>>>>> structure back-support. Our customers will simply not hear of reindexing
10s
>>>>> of TBs of content because of version upgrades. Such a decision is key
to
>>>>> Lucene adoption in large-scale projects. It's entirely not about whether
>>>>> Lucene is a content store or not - content is stored on other systems,
I
>>>>> agree. But that doesn't mean reindexing it is tolerable.
>>>>>
>>>>
>>>> I don't understand how its helpful to do a MAJOR version upgrade without
>>>> reindexing... what in the world do you stand to gain from that?
>>>> The idea here, is that development can be free of such hassles.
>>>> Development should be this way.
>>>> If you, Shai, need some feature X.Y.Z from Version 4 and don't want to
>>>> reindex, and are willing to do the work to port it back to Version 3 in a
>>>> completely backwards compatible way, then under this new scheme it can
>>>> happen.
>>>>
>>>> --
>>>> Robert Muir
>>>> rcmuir@gmail.com
>>>
>>
>>
>>
>> --
>> Robert Muir
>> rcmuir@gmail.com
>
>



-- 
Kirill Zakharenko/Кирилл Захаренко (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
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message