I think an index upgrade tool is okay? While you still definetly have to code it, things like "if idxVer==m doOneStuff elseif idxVer==n doOtherStuff else blowUp" are kept away from lucene innards and we all profit?
On Thu, Apr 15, 2010 at 16: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
