Hi Bob, No idea if this would work BUT...
If the old index is optimized then you might be able to iterate through all the docs in your old index (sorted by doc id) and for each iteration add the corresponding doc to the new index so it has a matching doc id. The idea being that after searching on one index you could use the doc id to look up the corresponding doc in the other index. It's just so crazy, it might just work! Rob. -----Original Message----- From: Bob Arens [mailto:[EMAIL PROTECTED] Sent: 09 June 2006 04:43 To: java-user@lucene.apache.org Subject: Adding Fields to Documents with UnStored Fields - crazy scheme? Hi, I've been handed a legacy index containing Documents with two Fields; one is a file ID, the other is contents of the file. The contents field was added using UnStored. Now, we want to add fields. Oh, the humanity! I've looked through the archives, and previously suggested methods won't work well for us. 1. Recreating with Luke is infeasible, as our index is 1.8 Gigabytes in size. 2. Recreating the index from scratch will require the moving of the heavens and the earth. My crazy idea - can we add new Documents to the index with the Fields we wish to add, and duplicate file IDs? i.e. an entry for file ID Foo would consist of two Documents, Document X: fileID:<Foo>, contents:<unknown> Document Y:fileID:<Foo>, title:<Bar>, url:<www.baz.com>, etc. It would be no problem to implement different Searcher objects to look at specific Fields, we were already leaning in that direction anyhow. So - is this scheme crazy enough to work? Thanks for your thoughts, Bob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
