Seamless online upgrades have their place too... say you are upgrading one server at a time in a cluster.
-Yonik Apache Lucene Eurocon 2010 18-21 May 2010 | Prague On Thu, Apr 15, 2010 at 8:42 AM, Earwin Burrfoot <ear...@gmail.com> wrote: > 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 <torin...@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 <rcm...@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 <torin...@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 <rcm...@gmail.com> wrote: >>>>> >>>>> >>>>> On Thu, Apr 15, 2010 at 7:52 AM, Shai Erera <ser...@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 >>>>> rcm...@gmail.com >>>> >>> >>> >>> >>> -- >>> Robert Muir >>> rcm...@gmail.com >> >> > > > > -- > Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 > > --------------------------------------------------------------------- > 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
