Re: patch: adding IndexReader.isCurrent()

Well, Radomir, the person who asked about that method should be on java-dev@, so I'll assume he'll speak up if he needs that method. I think isCurrent() is good to go. Otis --- Daniel Naber <[EMAIL PROTECTED]> wrote: > On Friday 03 June 2005 23:51, Otis Gospodnetic wrote: > > > Isn't version

Re: patch: adding IndexReader.isCurrent()

On Friday 03 June 2005 23:51, Otis Gospodnetic wrote: > Isn't version a time stamp now? It starts as a time stamp, but then +1 is added for each change. So that number has no useful meaning I think. It's only useful for comparison. Or am I missing something? Regards Daniel -- http://www.dan

Re: patch: adding IndexReader.isCurrent()

Isn't version a time stamp now? Somebody may still want to have that and keep track of that "long" outside Lucene. I think that's what that person wanted. Otis --- Daniel Naber <[EMAIL PROTECTED]> wrote: > On Friday 03 June 2005 23:18, Otis Gospodnetic wrote: > > > Looks good to me. You may

Re: patch: adding IndexReader.isCurrent()

On Friday 03 June 2005 23:18, Otis Gospodnetic wrote: > Looks good to me.  You may also want to add that instance method to > IndexReader that somebody asked for the other day... Well, the "version" isn't a version number anymore, at least not one that starts with 0 or 1. That's why those metho

Re: patch: adding IndexReader.isCurrent()

Looks good to me. You may also want to add that instance method to IndexReader that somebody asked for the other day... Here: "Hello, Am I missing an obvious way to return version of already opened index? Static method IndexReader.getCurrentVersion() uses SegmentInfos to read version number fr

patch: adding IndexReader.isCurrent()

Hi, a patch similar to this was proposed a year ago but then got lost. I will apply it unless someone objects. It fixes the problem that you cannot safely use IndexReader.getCurrentVersion() to detect changes, as the version number is reset to 0 if the index is re-created. Also see http://www

Re: compound file documentation

Daniel Naber wrote: On Friday 03 June 2005 19:02, Doug Cutting wrote: FileLength[i] -> (i==FileCount) ? DataOffset[i+1] : EOF) - DataOffset[n] Not sure if that really helps. At least I find it confusing, as neither the "?" operator nor the "EOF" occurs anywhere else in the document (actu

Re: compound file documentation

On Friday 03 June 2005 19:02, Doug Cutting wrote: > FileLength[i]  -> >    (i==FileCount) ? DataOffset[i+1] : EOF) - DataOffset[n] Not sure if that really helps. At least I find it confusing, as neither the "?" operator nor the "EOF" occurs anywhere else in the document (actually the "?" does o

Re: class for delete/add access to an index

On Friday 03 June 2005 18:43, Doug Cutting wrote: > As for names, IndexWriter would be a good one for this, and > IndexAppender would be a better name for what's now called IndexWriter. Actually I'd now like to add searching capabilities. Then Index, IndexAccess, or IndexAccessor would be okay.

DO NOT REPLY [Bug 35037] - [PATCH] Some Field methods use Classcast check instead of instanceof which is slow

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: compound file documentation

Daniel Naber wrote: can someone please check my changes to fileformats.xml regarding the compound format? (not yet on the website, call "ant" in the "site" directory to build the files locally). Looks good. One improvement: You could define FileData more formally as something like: FileData

Re: class for delete/add access to an index

Daniel Naber wrote: What do you think? If this gets accepted, it also needs a better name. It looks reasonable to me. As for names, IndexWriter would be a good one for this, and IndexAppender would be a better name for what's now called IndexWriter. Unfortunately, I don't see a way to make

Re: FieldCache parser

Hi Doug, Based upon your changes I have reworked a contribution for efficient sorting of "long" values which I submitted some time back numbered 34563 in Bugzilla. Please let me know if you have any questions, comments, or concerns. Regards, Rus On 6/2/05, Doug Cutting <[EMAIL PROTECTED]> wrote:

DO NOT REPLY [Bug 34563] - Contribution: Efficient Sorting of DateField/DateTools Encoded Timestamp Long Values

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34331] - Surround query language

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33648] - fileformats.xml doesn't document compound file streams

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34331] - Surround query language

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu