[jira] Updated: (LUCENE-1749) FieldCache introspection API

2009-08-11 Thread Hoss Man (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-1749: - Attachment: LUCENE-1749.patch slightly revised patch based on java-...@lucene discussion... the

[jira] Commented: (LUCENE-533) SpanQuery scoring: SpanWeight lacks a recursive traversal of the query tree

2009-08-11 Thread Paul Elschot (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741730#action_12741730 ] Paul Elschot commented on LUCENE-533: - One problem here is that the Spans interface

Re: who clears attributes?

2009-08-11 Thread Michael Busch
I'm not just responding to just you there, but more to the growing pack of those speaking against the new API. I don't see specific issues being brought up - the only issues I have seen brought up have been addressed in JIRA issues that have received no comments indicating the fix was not

Re: 2.5 versus 2.9, was Re: who clears attributes?

2009-08-11 Thread Michael McCandless
On Mon, Aug 10, 2009 at 9:12 PM, Grant Ingersollgsing...@apache.org wrote: Or... and this is one crazy idea... maybe we should simply release 3.0 next, not removing any deprecated APIs until 3.1 or later.  Ie, normal software on having so many major changes would release an X.0 release; I

[jira] Resolved: (LUCENE-1792) new QueryParser fails to set AUTO REWRITE for multi-term queries

2009-08-11 Thread Michael McCandless (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1792. Resolution: Fixed new QueryParser fails to set AUTO REWRITE for multi-term

[jira] Commented: (LUCENE-1790) Add Boosting Function Term Query and Some Payload Query refactorings

2009-08-11 Thread Michael McCandless (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741791#action_12741791 ] Michael McCandless commented on LUCENE-1790: Is this done? Add Boosting

[jira] Commented: (LUCENE-1790) Add Boosting Function Term Query and Some Payload Query refactorings

2009-08-11 Thread Michael McCandless (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741792#action_12741792 ] Michael McCandless commented on LUCENE-1790: Should we deprecate

Re: who clears attributes?

2009-08-11 Thread Robert Muir
On Tue, Aug 11, 2009 at 4:28 AM, Michael Buschbusch...@gmail.com wrote: There was a performance test in Solr that apparently ran much slower after upgrading to the new Lucene jar. This test is testing a rather uncommon scenario: very very short documents. Actually, its more uncommon than that:

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741804#action_12741804 ] Yonik Seeley commented on LUCENE-1794: -- bq. I am thinking of expanding this patch to

Re: who clears attributes?

2009-08-11 Thread Yonik Seeley
On Tue, Aug 11, 2009 at 6:50 AM, Robert Muirrcm...@gmail.com wrote: On Tue, Aug 11, 2009 at 4:28 AM, Michael Buschbusch...@gmail.com wrote: There was a performance test in Solr that apparently ran much slower after upgrading to the new Lucene jar. This test is testing a rather uncommon

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Robert Muir (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741805#action_12741805 ] Robert Muir commented on LUCENE-1794: - {quote} Now the problem: TokenStream.reset()

Re: who clears attributes?

2009-08-11 Thread Grant Ingersoll
On Aug 11, 2009, at 4:28 AM, Michael Busch wrote: I'm not just responding to just you there, but more to the growing pack of those speaking against the new API. I don't see specific issues being brought up - the only issues I have seen brought up have been addressed in JIRA issues that

Re: who clears attributes?

2009-08-11 Thread Earwin Burrfoot
On Tue, Aug 11, 2009 at 15:09, Yonik Seeleyyo...@lucidimagination.com wrote: On Tue, Aug 11, 2009 at 6:50 AM, Robert Muirrcm...@gmail.com wrote: On Tue, Aug 11, 2009 at 4:28 AM, Michael Buschbusch...@gmail.com wrote: There was a performance test in Solr that apparently ran much slower after

Re: who clears attributes?

2009-08-11 Thread Mark Miller
Earwin Burrfoot wrote: The only person that tried to disprove this claim is Uwe. Others either say the problems are solved, so it's okay to move to the new API, or this will be usable when flexindexing arrives. Others (not me) have spent a lot of time going over this before (more than once I

Re: who clears attributes?

2009-08-11 Thread Earwin Burrfoot
The only person that tried to disprove this claim is Uwe. Others either say the problems are solved, so it's okay to move to the new API, or this will be usable when flexindexing arrives. Others (not me) have spent a lot of time going over this before (more than once I think) - they prob are

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741810#action_12741810 ] Yonik Seeley commented on LUCENE-1794: -- For something like CachingTokenFilter to

Re: who clears attributes?

2009-08-11 Thread Mark Miller
Earwin Burrfoot wrote: The only person that tried to disprove this claim is Uwe. Others either say the problems are solved, so it's okay to move to the new API, or this will be usable when flexindexing arrives. Others (not me) have spent a lot of time going over this before (more than

[jira] Resolved: (LUCENE-1790) Add Boosting Function Term Query and Some Payload Query refactorings

2009-08-11 Thread Grant Ingersoll (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved LUCENE-1790. - Resolution: Fixed Lucene Fields: (was: [Patch Available]) Deprecated

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Robert Muir (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741813#action_12741813 ] Robert Muir commented on LUCENE-1794: - yonik, I see your point. get rid of your

[jira] Commented: (LUCENE-1689) supplementary character handling

2009-08-11 Thread Robert Muir (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741815#action_12741815 ] Robert Muir commented on LUCENE-1689: - this is just a reminder that I think if we go

Re: who clears attributes?

2009-08-11 Thread Michael McCandless
I think extensible analysis (the new TokenStream API) is a net positive: it gives us strongly typed and high performance extensibility to a Token, so apps can now add whatever attrs they want. And, I see it as the first (of 3) big legs that we need to reach flexible indexing. We really have to

[jira] Assigned: (LUCENE-1800) QueryParser should use reusable token streams

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley reassigned LUCENE-1800: Assignee: Yonik Seeley QueryParser should use reusable token streams

[jira] Created: (LUCENE-1800) QueryParser should use reusable token streams

2009-08-11 Thread Yonik Seeley (JIRA)
QueryParser should use reusable token streams - Key: LUCENE-1800 URL: https://issues.apache.org/jira/browse/LUCENE-1800 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.9

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741837#action_12741837 ] Mark Miller commented on LUCENE-1794: - bq. This would argue for a rewind() method. Is

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Robert Muir (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741839#action_12741839 ] Robert Muir commented on LUCENE-1794: - personally I like this idea. CachingTokenFilter

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741848#action_12741848 ] Yonik Seeley commented on LUCENE-1794: -- I don't think we need a rewind() at all on

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741849#action_12741849 ] Mark Miller commented on LUCENE-1794: - So what do you propose ? You would just cast

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741856#action_12741856 ] Mark Miller commented on LUCENE-1794: - Or even a Rewindable interface that can

[jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741859#action_12741859 ] Yonik Seeley commented on LUCENE-1794: -- It depends on the use case for

Re: [jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Mark Miller
Just as note related to this discussion: TokenFilter#reset says: /** Reset the filter as well as the input TokenStream. */ However, CachingTokenFilter does not reset the input TokenStream. - To unsubscribe, e-mail:

Re: [jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Yonik Seeley
On Tue, Aug 11, 2009 at 9:32 AM, Mark Millermarkrmil...@gmail.com wrote: Just as note related to this discussion: TokenFilter#reset says:  /** Reset the filter as well as the input TokenStream. */ However, CachingTokenFilter does not reset the input TokenStream. Yeah - I caught that as

RE: [jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers

2009-08-11 Thread Uwe Schindler
Just as note related to this discussion: TokenFilter#reset says: /** Reset the filter as well as the input TokenStream. */ However, CachingTokenFilter does not reset the input TokenStream. That's a bug :-) but it is not a problem, as CachingTokenFilter will not call the input filter

[jira] Commented: (LUCENE-1799) Unicode compression

2009-08-11 Thread Earwin Burrfoot (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741868#action_12741868 ] Earwin Burrfoot commented on LUCENE-1799: - I think right now this can be

Beta (was Re: who clears attributes?)

2009-08-11 Thread DM Smith
On 08/11/2009 08:22 AM, Michael McCandless wrote: I do still think a longish 2.9 beta is warranted, if we can succeed in getting users outside the dev group to kick the tires and uncover stuff. I think a beta would be a great idea. Not sure it needs to be longish. Having not looked at it,

Re: who clears attributes?

2009-08-11 Thread DM Smith
Uwe, Is this example available? I think that an example like this would help the user community see the current value in the change. At least, I'd love to see the code for it. -- DM On 08/10/2009 06:49 PM, Uwe Schindler wrote: UIMA The new API looks like UIMA, you have streams that

[jira] Commented: (LUCENE-1796) Speed up repeated TokenStream init

2009-08-11 Thread Yonik Seeley (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741952#action_12741952 ] Yonik Seeley commented on LUCENE-1796: -- Token.clear() used to be called by the

[jira] Commented: (LUCENE-1796) Speed up repeated TokenStream init

2009-08-11 Thread Uwe Schindler (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741957#action_12741957 ] Uwe Schindler commented on LUCENE-1796: --- bq. I don't know if all of the Tokenizers

[jira] Created: (LUCENE-1801) Tokenizers (which are the source of Tokens) should call AttributeSource.clearAttributes() first

2009-08-11 Thread Uwe Schindler (JIRA)
Tokenizers (which are the source of Tokens) should call AttributeSource.clearAttributes() first --- Key: LUCENE-1801 URL:

RE: Beta (was Re: who clears attributes?)

2009-08-11 Thread Steven A Rowe
Here's my (non-binding) -1 for a 2.9 beta. Before Lucene started using an X.Y.Z release naming process (v1.4 or thereabouts), releases generally had multiple release candidates. This left Lucene in quasi-released limbo for long periods of time. My take on the switch to an X.Y.Z release

The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Mark Miller
I don't think we should stick with the current path of replacing the current QueryParser with the new contrib QueryParser in Lucene 3.0. The new QueryParser has not been used much at all yet. Its interfaces (which will need to abide by back compat in core) have not been vetted enough. The

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Grant Ingersoll
+1, old QP should not be deprecated. Since the new one is in contrib, it should just be stated that it doesn't necessarily have the same back compat. issues as core, either that or it is marked as experimental. -Grant On Aug 11, 2009, at 1:54 PM, Mark Miller wrote: I don't think we

RE: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Uwe Schindler
Yes, we should not deprecate the old one! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Tuesday, August 11, 2009 8:32 PM To:

[jira] Commented: (LUCENE-1801) Tokenizers (which are the source of Tokens) should call AttributeSource.clearAttributes() first

2009-08-11 Thread Uwe Schindler (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742012#action_12742012 ] Uwe Schindler commented on LUCENE-1801: --- There is an additional problem (mentioned

Re: who clears attributes?

2009-08-11 Thread Michael Busch
On 8/11/09 4:13 AM, Grant Ingersoll wrote: On Aug 11, 2009, at 4:28 AM, Michael Busch wrote: I'm not just responding to just you there, but more to the growing pack of those speaking against the new API. I don't see specific issues being brought up - the only issues I have seen brought up

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742037#action_12742037 ] Mark Miller commented on LUCENE-1771: - I think the Changes entries could still use

[jira] Commented: (LUCENE-533) SpanQuery scoring: SpanWeight lacks a recursive traversal of the query tree

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742045#action_12742045 ] Mark Miller commented on LUCENE-533: Paul: Spans is breaking back compat in this

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

2009-08-11 Thread Michael McCandless (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742051#action_12742051 ] Michael McCandless commented on LUCENE-1771: Maybe say Weight#explain now

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Erik Hatcher
Agreed, don't deprecate our beloved QueryParser. Erik On Aug 11, 2009, at 1:54 PM, Mark Miller wrote: I don't think we should stick with the current path of replacing the current QueryParser with the new contrib QueryParser in Lucene 3.0. The new QueryParser has not been used much

Re: who clears attributes?

2009-08-11 Thread Grant Ingersoll
On Aug 11, 2009, at 3:21 PM, Michael Busch wrote: On 8/11/09 4:13 AM, Grant Ingersoll wrote: On Aug 11, 2009, at 4:28 AM, Michael Busch wrote: I'm not just responding to just you there, but more to the growing pack of those speaking against the new API. I don't see specific issues

[jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742063#action_12742063 ] Mark Miller commented on LUCENE-1771: - Okay - just ran the tests one more time and

[jira] Created: (LUCENE-1802) Un-deprecate QueryParser and remove documentation that says it will be replaced in 3.0

2009-08-11 Thread Mark Miller (JIRA)
Un-deprecate QueryParser and remove documentation that says it will be replaced in 3.0 -- Key: LUCENE-1802 URL: https://issues.apache.org/jira/browse/LUCENE-1802

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Michael McCandless
+1 Mike On Tue, Aug 11, 2009 at 5:43 PM, Michael Buschbusch...@gmail.com wrote: I agree we should not remove the old one in 3.0. That's way too early. If we change the bw-policy we can replace it maybe in 3.1. On 8/11/09 11:40 AM, Uwe Schindler wrote: Yes, we should not deprecate the old

RE: who clears attributes?

2009-08-11 Thread Uwe Schindler
Hi DM, It is not public at the moment and still in development. I can public the XML tokenizer when it is finished. In general it shows one possible use-case for custom attributes. Maybe we get something like this in future: Just tag all tokens with the field name (using a

[jira] Commented: (LUCENE-1577) Benchmark of different in RAM realtime techniques

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742101#action_12742101 ] Mark Miller commented on LUCENE-1577: - bq. normally bulk indexing is done up front,

[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742104#action_12742104 ] Mark Miller commented on LUCENE-1748: - I'm tempted to make Spans abstract. We don't

[jira] Closed: (LUCENE-1029) Illegal character replacements in ISOLatin1AccentFilter

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller closed LUCENE-1029. --- Resolution: Invalid The new ASCIIFoldingFilter is the current best work on this. Future issues

[jira] Commented: (LUCENE-636) [PATCH] Differently configured Lucene 'instances' in same JVM

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742131#action_12742131 ] Mark Miller commented on LUCENE-636: Both of the properties Hoss mentioned are now

[jira] Commented: (LUCENE-1720) TimeLimitedIndexReader and associated utility class

2009-08-11 Thread Jason Rutherglen (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742138#action_12742138 ] Jason Rutherglen commented on LUCENE-1720: -- I am interested in using this code,

[jira] Resolved: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.

2009-08-11 Thread Mark Miller (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved LUCENE-1771. - Resolution: Fixed committed - thanks all! Using explain may double ram reqs for fieldcaches

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Shai Erera
Mark, I support not deprecating the current QP. But I just wanted to comment on let's wait 'till people add more syntaxes. I don't think that that's the issue here. The new QP is indeed useful for plugging in different search syntaxes, but I personally don't believe that in an application more

[jira] Commented: (LUCENE-636) [PATCH] Differently configured Lucene 'instances' in same JVM

2009-08-11 Thread Ken Geis (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742212#action_12742212 ] Ken Geis commented on LUCENE-636: - I would not close this until the code is removed, not

[jira] Commented: (LUCENE-1768) NumericRange support for new query parser

2009-08-11 Thread Adriano Crestani (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742223#action_12742223 ] Adriano Crestani commented on LUCENE-1768: -- {quote} The proposed RangeTools seems

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Jason Rutherglen
I'm starting to use the new parser to emulate Google's queries (i.e. a phrase query with a single term means no-stemming, something the current QP doesn't allow because it converts the quoted query into a term query inside the JavaCC portion). It's been very straightforward and logical to use (so