On 04/15/2010 03:12 PM, Earwin Burrfoot wrote:
On Thu, Apr 15, 2010 at 23:07, DM Smith<dmsmith...@gmail.com> wrote:
On 04/15/2010 03:04 PM, Earwin Burrfoot wrote:
BTW Earwin, we can come up w/ a migrate() method on IW to accomplish
manual migration on the segments that are still on old versions.
That's not the point about whether optimize() is good or not. It is
the difference between telling the customer to run a 5-day migration
process, or a couple of hours. At the end of the day, the same
migration code will need to be written whether for the manual or
automatic case. And probably by the same developer which changed the
index format. It's the difference of when does it happen.
Converting stuff is easier then emulating, that's exactly why I want a
separate tool.
There's no need to support cross-version merging, nor to emulate old APIs.
I also don't understand why offline migration is going to take days
instead of hours for online migration??
WTF, it's gonna be even faster, as it doesn't have to merge things.
Will it be able to be used within a client application that creates and uses
local indexes?
I;m assuming it will be faster than re-indexing.
As I said earlier in the topic, it is obvious the tool has to have
both programmatic and command-line interfaces.
I will also reiterate - it only upgrades the index structurally. If
you changed your analyzers - that's your problem and you have to deal
with it
Good. (Sorry I missed that. There's just too much in the thread to keep
track of ;)
As long as my "old" analyzers will still work with the new lucene-core
jar, I'm fat, dumb and happy with the upgraded index.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
