DO NOT REPLY [Bug 4102] New: - Prefix Queries cannot be case insensitible

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://nagoya.apache.org/bugzilla/show_bu

AW: Token retrieval question

Hey, great, at least my ideas are not entirely wrong. It seems like both solutions would suffice for me right now. Solution 2 would be the more elegant route to go. I cannot estimate how much work is involved. How much time do you expect is needed. What can I contribute to that? Fact is that th

DO NOT REPLY [Bug 4105] New: - Prefix Queries cannot be case insensitible

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://nagoya.apache.org/bugzilla/show_bu

Null pointer error when searching with DateFilter

Hello all, I am trying to search using a DateFilter so I get a resultset that lies between two dates. Without the DateFilter the search works perfectly, but when I use the DateFilter I get the following error java.lang.NullPointerException at org.apache.lucene.index.SegmentTermEn

RE: Null pointer error when searching with DateFilter

Yes, this is the exact error that I've addressed in the patch I'm about to check in for SegmentTermEnum. Scott > -Original Message- > From: Anders Nielsen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 11, 2001 9:57 AM > To: [EMAIL PROTECTED] > Subject: Null pointer error when sear

RE: Null pointer error when searching with DateFilter

Should I ever find a suitable woman (blind or drunk), our first offspring shall proudly bear the name Scott.. In other words: thanks regards, Anders Nielsen -Original Message- From: Scott Ganyo [mailto:[EMAIL PROTECTED]] Sent: 11. oktober 2001 17:07 To: '[EMAIL PROTECTED]' Subject: RE:

cvs commit: jakarta-lucene/src/java/org/apache/lucene/index SegmentTermEnum.java

scottganyo01/10/11 08:14:14 Modified:src/java/org/apache/lucene/index SegmentTermEnum.java Log: Fix NullPointerException in clone() method when the Term is null. Revision ChangesPath 1.2 +1 -1 jakarta-lucene/src/java/org/apache/lucene/index/SegmentTermEnum.ja

cvs commit: jakarta-lucene/src/java/org/apache/lucene/search RangeQuery.java

scottganyo01/10/11 08:19:38 Modified:src/java/org/apache/lucene/search RangeQuery.java Log: Fix issue where an inclusive range query would include the nearest term in the index above a non-existant specified upper term. Revision ChangesPath 1.2 +7 -4 jakarta-

DO NOT REPLY [Bug 4105] - Prefix Queries cannot be case insensitible

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://nagoya.apache.org/bugzilla/show_bu

RE: Null pointer error when searching with DateFilter

Kind words indeed! Thanks. :) I've checked in now, so please check it out and verify the fix for yourself. (By the way, another way to address a date range selection is with the RangeQuery I added a while back. You can include in your main query and in many circumstances it may be faster than

RE: multithreading in SegmentsReader

> From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] > > Yes, that sounds fine. Delete can definetely just be a synchronized > method. And so can the numDocs unless it is called a lot. Is > it? If it > is, we may want to leave the upfront check in there before it is > synchronized. It shou

Bug in new Index Lock File code ?

First, I would like to appologise for this message being so long, but I have tried to provide sufficient information for somone to potentialy help me diagnose my problem - this being that using the latest build of lucene causes corruption of my indexes, whereas earlier releases of lucene from sou

RE: skipTo()

This would be hard to fix without modifying the TermDocs API. This could be construed as just a documentation problem. Perhaps this method should be documented so that 'target' must be strictly greater than the current document. Doug > -Original Message- > From: Dmitry Serebrennikov [m

cvs commit: jakarta-lucene/src/java/org/apache/lucene/store FSDirectory.java

cutting 01/10/11 10:21:10 Modified:src/java/org/apache/lucene/store FSDirectory.java Log: Fixed so that getDirectory(xxx,true) correctly erases the directory contents, even when the directory has already been accessed in this JVM. This was broken by the thread-safety fix.

RE: Bug in new Index Lock File code ?

Joanne, It looks like you have spotted a bug in FSDirectory. However I am not sure if it is what is causing the problems you are seeing. I just checked a fix for this into CVS. Please try this newe version and tell me how things go. One thing that might be confusing you is the file names in y

Re: multithreading in SegmentsReader

Doug Cutting wrote: >>From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] >> >>Yes, that sounds fine. Delete can definetely just be a synchronized >>method. And so can the numDocs unless it is called a lot. Is >>it? If it >>is, we may want to leave the upfront check in there before it is

Re: skipTo()

Yes, I realized that after I sent the message. Maybe there is a need for a convinence method that checks the current doc first and then calls skipTo if needed. Doug Cutting wrote: >This would be hard to fix without modifying the TermDocs API. This could be >construed as just a documentation p

Katakana characters in queries (a bug?)

Hi! There seem to be a bug in the lucene-1.2-rc1.jar distribution. Searching for the following string returns an error message from the query parser. String katakana = "\u30AB\u30BF\u30AB\u30CA"; - - - org.apache.lucene.queryParser.TokenMgrError: Lexical error at line 1, column 10. Encounte

Another minor synchro change: SegmentReader

This prevents reading norm factors multiple times on the first access for a given field. Like I said, it's minor... Index: SegmentReader.java === RCS file: /home/cvspublic/jakarta-lucene/src/java/org/apache/lucene/index/SegmentRead

RE: multithreading in SegmentsReader

> From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] > > But I was looking again at the MultiSearcher after reading > through the SegmentsReader (and friends) and I was > thinking if it wouldn't be better to write MultiSearcher > not in terms of searching over multiple Searchers, but as > an I

Added comments to InputStream and OutputStream

I figured that I might as well be adding comments as I am reading and figuring out the code. One thing I was not clear on - characters are stored with 1 to 3 bytes. Is that sufficient to represent all Unicode characters? I thought Unicode was four bytes. Index: InputStream.java ===

Re: multithreading in SegmentsReader

Doug Cutting wrote: >Yes, there is some duplication between MultiSearcher and SegmentsReader. >The reason for keeping these separate was to support distributed searching. > I see. > >Thus the Searcher API is designed to have only small bits of data pass >through it. I never actually implement

RE: Token retrieval question

> From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] > > Doug, thanks for posting these. I may end up going in this > direction in > the next few days and will use this as a blueprint. Maybe I'll end up > putting in the first pass implementation and then you can > later further > tune it

Re: Token retrieval question

Doug Cutting wrote: >>From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] >> >>Doug, thanks for posting these. I may end up going in this >>direction in >>the next few days and will use this as a blueprint. Maybe I'll end up >>putting in the first pass implementation and then you can >>la

cvs commit: jakarta-lucene/src/java/org/apache/lucene/index SegmentsReader.java

cutting 01/10/11 15:44:23 Modified:src/java/org/apache/lucene/index SegmentsReader.java Log: Fixed potential race condition. Revision ChangesPath 1.2 +2 -2 jakarta-lucene/src/java/org/apache/lucene/index/SegmentsReader.java Index: SegmentsReader.java =

RE: Token retrieval question

>From what I remember, lucene indices are structures like: ...> where for every TERM there is a list of DOCs in which it appears and the respective POSitions in that DOC. Our problem is that TERM, usually, is a non-word (or stem). For display purposes, having a real word as the representative f

Re: Token retrieval question

Excellent! This is a good confirmation of my direction. I have a question to the list - are there any votes out there for including this kind of "stem reversal" into Lucene, or does it more properly belong outside of Lucene, in the application using it? (I'm leaving the text below for easy refe