Filed a Jira issue:
http://issues.apache.org/jira/browse/LUCENE-573
Tomislav
--
View this message in context:
http://www.nabble.com/ParseException-with-escaped-quotes-in-a-phrase-t1647115.html#a4463298
Sent from the Lucene - Java Developer forum at Nabble.com.
Escaped quotes inside a phrase cause a ParseException
-
Key: LUCENE-573
URL: http://issues.apache.org/jira/browse/LUCENE-573
Project: Lucene - Java
Type: Bug
Components: QueryParser
Versions: 1.9
Envir
: Looks like QueryParser doesn't handle escaped quotes when inside a phrase:
I believe you are correct. could you file a Jira issue for this,
preferably with your main function converted to a JUnit test function that
can be added to TestQueryParser?
(it doesn't take much to write a JUnit test f
[
http://issues.apache.org/jira/browse/LUCENE-561?page=comments#action_12412460 ]
Chuck Williams commented on LUCENE-561:
---
Yonik, thanks for looking at this, and good catch! If there are multiple seeks
on the termDocs, one is performed on a known fie
[
http://issues.apache.org/jira/browse/LUCENE-561?page=comments#action_12412459 ]
Yonik Seeley commented on LUCENE-561:
-
Chuck, I took a very quick scan, most of it looks fine.
What about seek() calls though... if the reader is null, shouldn't termDocs b
Looks like QueryParser doesn't handle escaped quotes when inside a phrase:
public static void main(String[] args) throws Exception {
String s = "Re:abcde jjj\"efgh asdf\" dsfdsf";
System.out.println(s);
QueryParser parser = new QueryParser("subject", new StandardAnalyzer()
I think Lucene-561 is in the "egregious" category and it has a patch to
fix it (be sure to get the most recent of the two). Can this be included?
Chuck
Yonik Seeley wrote on 05/18/2006 10:50 AM:
> On 5/18/06, DM Smith <[EMAIL PROTECTED]> wrote:
>> > at the monent, there are two Jira issues with
: I wouldn't seeing 415 being fixed, but I seem to be missing a way one
: changes "Fix Version".
it's a property that can be changed from the edit screen .. but 415 is
weird, there is no "Edit" link in the Operations nav (as opposed to every
other LUCENE issue i've ever looked at )
-Hoss
On 5/18/06, DM Smith <[EMAIL PROTECTED]> wrote:
> at the monent, there are two Jira issues with a "Fix" version of 2.0 still
> unresolved: LUCENE-556 and LUCENE-546
I wouldn't seeing 415 being fixed, but I seem to be missing a way one
changes "Fix Version".
-Yonik
http://incubator.apache.org/s
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12412415 ]
Yonik Seeley commented on LUCENE-415:
-
Andy, how easy is it for you to replicate the problems that getChannel()
solved? Is it possible to check if the addition of setLeng
Chris Hostetter wrote:
: Could someone enumerate what needs to be done before 2.0 is released.
: From following this thread, it was stated that 2.0 was 1.9 with
: deprecations removed.
: Recently it appears to be becoming much more than that.
I believe Doug's suggestion was to hold off just l
: Could someone enumerate what needs to be done before 2.0 is released.
: From following this thread, it was stated that 2.0 was 1.9 with
: deprecations removed.
: Recently it appears to be becoming much more than that.
I believe Doug's suggestion was to hold off just long enough to fix any
egre
On May 18, 2006, at 10:43 AM, Robert Engels wrote:
Has anyone thought of (or implemented) caching of term information?
Currently, Lucene stores an index of every nTH term. Then uses this
information to position the TermEnum, and then scans the terms.
Might it be better to read a "page" of ter
I'm returning 20 results (about .5Kb each). In fact, I had to reduce that
from 50 because the network was becoming the bottleneck.
On the 16-cpu server, I ran tests using 8, 16 and 32 query threads, but
there was no improvement with more threads. I still believe the hardware was
to blame.
Peter
As someone else pointed out, the proposed mods will only affect queries the
return a lot of Documents. If your test is only set up to return a few
documents (or possible none at all), then you will see no difference.
The fact that some of the CPUs were far less than 100%, and others were at
100% m
Robert,
Sorry I missed your questions.
The test results seem hard to believe. Doubling the CPUs only increased
through put by 20%??? Seems rather low for primarily a "read only" test.
I think this refers to the test I did on a 16 cpu (32 hyperthreaded) server.
This system was actually two 8
Has anyone thought of (or implemented) caching of term information?
Currently, Lucene stores an index of every nTH term. Then uses this
information to position the TermEnum, and then scans the terms.
Might it be better to read a "page" of term infos (based on the index), and
then keep these pages
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12412384 ]
Andy Hind commented on LUCENE-415:
--
file.getChannel() was added on windows.
It was *before* the truncating file issue was found and resolved.
It is possible the two are relate
[
http://issues.apache.org/jira/browse/LUCENE-544?page=comments#action_12412382 ]
Otis Gospodnetic commented on LUCENE-544:
-
But of course.
> MultiFieldQueryParser field boost multiplier
>
>
> Ke
[
http://issues.apache.org/jira/browse/LUCENE-554?page=comments#action_12412381 ]
Otis Gospodnetic commented on LUCENE-554:
-
Patrick - unfortunately, my suggestion was naive, as Nadav quickly pointed out,
so I'm not sure which patch you are referrin
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12412379 ]
Yonik Seeley commented on LUCENE-415:
-
the fact that getChannel has side effects in Windows makes me a little
uncomfortable about what other side effects it has on other p
On Thu, 2006-05-18 at 09:41 -0400, Erik Hatcher wrote:
> On May 18, 2006, at 9:19 AM, DM Smith wrote:
> > I'd like to see a 2.0 now and if there are changes then
> > subsequent releases, say 2.0.1 for bugs and 2.1 for changes > to API
> or file structure (e.g. byte count vs char count)
>
> +1 fr
On May 18, 2006, at 9:19 AM, DM Smith wrote:
Could someone enumerate what needs to be done before 2.0 is released.
From following this thread, it was stated that 2.0 was 1.9 with
deprecations removed.
Recently it appears to be becoming much more than that.
Personally, I'd like to see a 2.0 n
Could someone enumerate what needs to be done before 2.0 is released.
From following this thread, it was stated that 2.0 was 1.9 with
deprecations removed.
Recently it appears to be becoming much more than that.
Personally, I'd like to see a 2.0 now and if there are changes then
subsequent rel
[
http://issues.apache.org/jira/browse/LUCENE-544?page=comments#action_12412338 ]
Karl Wettin commented on LUCENE-544:
Otis Gospodnetic commented on LUCENE-544:
> -
>
> Karl - can you submit this as a patch/diff,
Welcome Hoss! I've just moderated in your commit messages such that
future ones will go through unmoderated. Glad to have you committing!
Erik
On May 18, 2006, at 3:39 AM, [EMAIL PROTECTED] wrote:
Author: hossman
Date: Thu May 18 00:39:23 2006
New Revision: 407485
URL: http://sv
Hi
I think you may be hitting the same issue as me - see LUCENE-415.
Are you killing the JCR application or it has crashed?
If you are ...
It is probably mid merge, it has created a new segment file and part
written it...and died. The next merge it tries it uses the same
partially used segment f
[
http://issues.apache.org/jira/browse/LUCENE-554?page=comments#action_12412315 ]
Patrick Kimber commented on LUCENE-554:
---
This patch is exactly what we require. Our Lucene index often becomes unusable
when the "segments.new" file is not renamed to "
[ http://issues.apache.org/jira/browse/LUCENE-499?page=all ]
Hoss Man closed LUCENE-499:
---
> Documentation improvements for 1.9 release
> --
>
> Key: LUCENE-499
> URL: http://issues.apache.org/jira/brow
[ http://issues.apache.org/jira/browse/LUCENE-492?page=all ]
Hoss Man closed LUCENE-492:
---
> PhraseQuery.explain is broken
> -
>
> Key: LUCENE-492
> URL: http://issues.apache.org/jira/browse/LUCENE-492
> Proje
[ http://issues.apache.org/jira/browse/LUCENE-572?page=all ]
Hoss Man resolved LUCENE-572:
-
Resolution: Fixed
simple one line fix commited...
Index: src/java/org/apache/lucene/search/spans/SpanNotQuery.java
=
SpanNotQuery.hashCode ignores exclude
-
Key: LUCENE-572
URL: http://issues.apache.org/jira/browse/LUCENE-572
Project: Lucene - Java
Type: Bug
Components: Search
Reporter: Hoss Man
Assigned to: Hoss Man
Priority: Mino
[ http://issues.apache.org/jira/browse/LUCENE-352?page=all ]
Hoss Man resolved LUCENE-352:
-
Resolution: Fixed
commited patch
> [PATCH] NullPointerException when using nested SpanOrQuery in SpanNotQuery
>
[ http://issues.apache.org/jira/browse/LUCENE-352?page=all ]
Hoss Man updated LUCENE-352:
Bugzilla Id: (was: 33725)
Fix Version: 2.0
> [PATCH] NullPointerException when using nested SpanOrQuery in SpanNotQuery
>
34 matches
Mail list logo
