Sounds good. If other people find it useful, I'm all for it. I just didn't want to burden you guys to change the index format only for my use-case :-)
On Sat, Sep 6, 2008 at 3:44 PM, Michael McCandless < [EMAIL PROTECTED]> wrote: > > I think this may also be useful for a reader to have richer logic as to > whether it's time to reopen. It's a way for the writer to do some minimal > communication to the readers on what changes were just committed. > > Ie we have the static IndexReader.getVersion method, that opens the latest > segments_N in the index and returns its version; we'd add something like > static IndexReader.getLatestCommitUserData which IndexReader could consult > to see if it should reopen. > > In 3.0, when IndexWriter hardwires autoCommit to false, then every commit > is explicitly done by application code (vs now where merges, optimize, may > do commits as well), then the application would have total control on what > userData to put into the commit. > > I think this is compelling? It's a tiny change to the index format. > > Mike > > > markharw00d wrote: > > >> >>> I think this could be a generally useful feature? >>> >>> +1. I could definitely use a "commitUserData" option for the same >> reasons. >> >> Thinking more on this, we may not need to modify the index format at all >>> for >>> this use-case. This is easily achieved in the current system by adding a >>> dummy document which Solr can read/write -- not very elegant but it can >>> work >>> >>> >> I thought about this but was uncomfortable with the idea of adding an >> extra doc - some use cases that become troublesome for any application logic >> are: >> 1) IndexReader.numDocs/IndexReader.maxDoc will give "incorrect" values >> 2) Any queries of the type "all documents *without* a value for field X >> return the commit.userdata document. >> >> I was toying with the idea of maintaining my own commit.userdata file >> which I would manage in my framework when calling IndexWriter.commit but >> this does not feel as clean as Lucene core code holding the user data in the >> segments file. >> >> Cheers >> Mark >> >> >> --------------------------------------------------------------------- >> 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] > > -- Regards, Shalin Shekhar Mangar.
