Phew, this sounds much cleaner. I was getting a headache trying to understand everything being said here, on Solr lists, etc.
Otis ----- Original Message ---- From: Michael McCandless <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Wednesday, January 17, 2007 5:38:00 AM Subject: Re: adding "explicit commits" to Lucene? Grant Ingersoll wrote: > > On Jan 16, 2007, at 3:55 PM, Michael McCandless wrote: > >> Doron Cohen wrote: >>> Michael McCandless <[EMAIL PROTECTED]> wrote on 16/01/2007 >>> 12:13:47: >>>> Ning Li wrote: >> Re those 2 ideas: I do agree the whole division of certain kinds of >> index changes into a reader and other ones into a writer, is confusing >> to our users. I think our ideal eventual solution is a single "grand >> unified" Index class that efficiently does all things that IndexWriter >> and IndexReader do today. (I think this is closest to your 2nd option >> in that link). >> > > I'm all for efficiency, but I'd be wary of a grand unifying class > combining Reader/Writer operations as you've already hit the nail on the > head that the reader/writers are too confusing, combining them, without > significant refactoring simplification sounds like it would just make > matters worse since they both already have a fair number of methods on > them. To me, we need to better define what a Reader does and what a > Writer does and make the appropriate changes to the APIs. I agree: it's not clear how best to improve the confusion, short term or long term. I think the confusion indeed stems from the fact that IndexReader is used to make certain changes (deletes, norms) and IndexWriter is used for others (addDocuments, optimize, addIndices), and the fact that the nearly ubiquitous use case of reindexing changed documents requires one open IndexReader, do deletes, close (commit), open IndexWriter, do adds, close (commit). Perhaps instead of a single "grand unified Index" class in the future, we aim to move all index write methods into IndexWriter? This is then simple for users to use: if you want to change anything about the index, use an IndexWriter; if you want to do searches, use an IndexReader. If we aim for this as our eventual goal, LUCENE-565 in fact gets us quite a bit closer. Furthermore, if we did that, we can indeed simplify "explicit commits" to mean "nothing is visible to readers until you close your writer". This is the "commit only on close" idea that Doug suggested. With this new approach there would be no added commit() method. And, a writer would not write any segments_N (checkpoint) files until it is closed. I like this new implemenation for "explicit commits" better (thanks everyone for the feedback!). I will work through this / think about it more. Mike --------------------------------------------------------------------- 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]
