Thanks, Jason! Glad the new QP is useful for you.
I'd like to explain a bit the (IBM internal) history of this new QP: A
few years ago we wanted to change/extend Lucene's query syntax. We did
similar things as you mention, like no stemming for quoted terms,
additional syntax features, etc. Ver
[
https://issues.apache.org/jira/browse/LUCENE-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Fondermann updated LUCENE-1803:
-
Attachment: LowerCaseTokenizer_javadoc.patch
> Wrong javadoc on LowerCaseTokenizer.norma
Wrong javadoc on LowerCaseTokenizer.normalize
-
Key: LUCENE-1803
URL: https://issues.apache.org/jira/browse/LUCENE-1803
Project: Lucene - Java
Issue Type: Bug
Components: Javadocs
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742232#action_12742232
]
Uwe Schindler commented on LUCENE-1768:
---
I would propose to absorb the RangeTools/Ut
With the new QP we can build out a syntax that's compatible with
GData and be able to embed location/spatial queries directly
into the query string. (i.e. @+40.75-074.00 + 5mi)
SQL like range queries (i.e. [megapixel >= 3.0])
On Tue, Aug 11, 2009 at 10:44 PM, Jason
Rutherglen wrote:
> I'm startin
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 f
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742223#action_12742223
]
Adriano Crestani commented on LUCENE-1768:
--
{quote}
The proposed RangeTools seems
[
https://issues.apache.org/jira/browse/LUCENE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742212#action_12742212
]
Ken Geis commented on LUCENE-636:
-
I would not close this until the code is removed, not ju
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
[
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 w
[
https://issues.apache.org/jira/browse/LUCENE-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742138#action_12742138
]
Jason Rutherglen commented on LUCENE-1720:
--
I am interested in using this code, i
[
https://issues.apache.org/jira/browse/LUCENE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742131#action_12742131
]
Mark Miller commented on LUCENE-636:
Both of the properties Hoss mentioned are now depr
[
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
shou
[
https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742104#action_12742104
]
Mark Miller commented on LUCENE-1748:
-
I'm tempted to make Spans abstract. We don't ge
[
https://issues.apache.org/jira/browse/LUCENE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742101#action_12742101
]
Mark Miller commented on LUCENE-1577:
-
bq. normally bulk indexing is done up front, an
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 FieldNameAttribut
+1
Mike
On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch 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 one!
>>
>> -
[
https://issues.apache.org/jira/browse/LUCENE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742084#action_12742084
]
Jason Rutherglen commented on LUCENE-1577:
--
We need a benchmark that simply measu
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 one!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
e
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
Proj
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742063#action_12742063
]
Mark Miller commented on LUCENE-1771:
-
Okay - just ran the tests one more time and loo
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 bein
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 a
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742051#action_12742051
]
Michael McCandless commented on LUCENE-1771:
Maybe say "Weight#explain now tak
[
https://issues.apache.org/jira/browse/LUCENE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742045#action_12742045
]
Mark Miller commented on LUCENE-533:
Paul:
Spans is breaking back compat in this relea
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742037#action_12742037
]
Mark Miller commented on LUCENE-1771:
-
I think the Changes entries could still use som
+1
In other words: undeprecate our good friend 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
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
[
https://issues.apache.org/jira/browse/LUCENE-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742012#action_12742012
]
Uwe Schindler commented on LUCENE-1801:
---
There is an additional problem (mentioned a
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: java-dev@lucene.apache
+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 shoul
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 ne
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 proces
Tokenizers (which are the source of Tokens) should call
AttributeSource.clearAttributes() first
---
Key: LUCENE-1801
URL: https://issues.apache.org/jira/browse/LUCENE-1801
[
https://issues.apache.org/jira/browse/LUCENE-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741957#action_12741957
]
Uwe Schindler commented on LUCENE-1796:
---
bq. I don't know if all of the Tokenizers i
I thought 2.9 was on track to be released shortly, then the new
query parser and the further tokenizer changes (which were
apparently necessary) went in. It seems like we're putting too
many additions into this release at the last minute (which I
thought was targeted to be the end of the month?).
[
https://issues.apache.org/jira/browse/LUCENE-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741952#action_12741952
]
Yonik Seeley commented on LUCENE-1796:
--
Token.clear() used to be called by the consum
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
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
[
https://issues.apache.org/jira/browse/LUCENE-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741868#action_12741868
]
Earwin Burrfoot commented on LUCENE-1799:
-
I think right now this can be implement
> 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 fi
On Tue, Aug 11, 2009 at 9:32 AM, Mark Miller 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 well - but it does
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: java-dev-u
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741859#action_12741859
]
Yonik Seeley commented on LUCENE-1794:
--
It depends on the use case for CachingTokenFi
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741856#action_12741856
]
Mark Miller commented on LUCENE-1794:
-
Or even a Rewindable interface that can impleme
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741849#action_12741849
]
Mark Miller commented on LUCENE-1794:
-
So what do you propose ? You would just cast t
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741848#action_12741848
]
Yonik Seeley commented on LUCENE-1794:
--
I don't think we need a rewind() at all on To
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741839#action_12741839
]
Robert Muir commented on LUCENE-1794:
-
personally I like this idea. CachingTokenFilter
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741837#action_12741837
]
Mark Miller commented on LUCENE-1794:
-
bq. This would argue for a rewind() method.
Is
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741835#action_12741835
]
DM Smith commented on LUCENE-1794:
--
If CachingTokenFilter.reset() means rewind, then how
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
[
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
> -
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
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1794:
Attachment: LUCENE-1794.patch
add reset() impls for ngram/* and compound/*. These still need tests
[
https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741815#action_12741815
]
Robert Muir commented on LUCENE-1689:
-
this is just a reminder that I think if we go t
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741813#action_12741813
]
Robert Muir commented on LUCENE-1794:
-
yonik, I see your point.
"get rid of your sta
[
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 BoostingTe
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
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741810#action_12741810
]
Yonik Seeley commented on LUCENE-1794:
--
For something like CachingTokenFilter to work
>> 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) - t
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
On Tue, Aug 11, 2009 at 15:09, Yonik Seeley wrote:
> On Tue, Aug 11, 2009 at 6:50 AM, Robert Muir wrote:
>> On Tue, Aug 11, 2009 at 4:28 AM, Michael Busch wrote:
>>> There was a performance test in Solr that apparently ran much slower
>>> after upgrading to the new Lucene jar. This test is testing
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 h
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741805#action_12741805
]
Robert Muir commented on LUCENE-1794:
-
{quote}
Now the problem: TokenStream.reset() ha
On Tue, Aug 11, 2009 at 6:50 AM, Robert Muir wrote:
> On Tue, Aug 11, 2009 at 4:28 AM, Michael Busch 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
[
https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741804#action_12741804
]
Yonik Seeley commented on LUCENE-1794:
--
bq. I am thinking of expanding this patch to
On Tue, Aug 11, 2009 at 4:28 AM, Michael Busch 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: its very very s
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741792#action_12741792
]
Michael McCandless commented on LUCENE-1790:
Should we deprecate BoostingTermQ
[
https://issues.apache.org/jira/browse/LUCENE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741791#action_12741791
]
Michael McCandless commented on LUCENE-1790:
Is this done?
> Add Boosting Fun
[
https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741786#action_12741786
]
Michael McCandless commented on LUCENE-1792:
And then there were 6! Eventuall
[
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 queri
On Mon, Aug 10, 2009 at 9:12 PM, Grant Ingersoll 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 agree the
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 goo
[
https://issues.apache.org/jira/browse/LUCENE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741730#action_12741730
]
Paul Elschot commented on LUCENE-533:
-
One problem here is that the Spans interface doe
74 matches
Mail list logo
