You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Allahbaksh Mohammedali Asadullah <Al...@infosys.com> on 2009/03/09 10:41:48 UTC
Lucene 2.9
Hi,
When is Lucene 2.9 due? I am eagerly waiting for the new lucene to come.
As I compared Lucene with Minion I think Minion offers very rich capabilities like easier range query etc.
Is there any plans to have simpler queries for Numbers and Data?
No doubt lucene is the best Open Source Search library but I think Minion will catch up unless and until we make Lucene powerful to have pluggable query engine etc.
Lucene has strong user groups and also great tutorial. And best part is it is released in ASL.
Regards,
Allahbaksh
Allahbaksh Mohammedali Asadullah,
Software Engineering & Technology Labs,
Infosys Technolgies Limited, Electronics City,
Hosur Road, Bangalore 560 100, India.
*Board: +91-80-28520261 | Extn: 53915 | Direct: 41173915.
Fax: +91-80-28520362 | Mobile: +91-9845505322.
http://setlabs/slim/
http://allahbaksh.blogspot.com
Starting a startup is hard, but having a 9 to 5 job is hard too, and in some ways a worse kind of hard.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: Lucene 2.9
Posted by Luis Alves <la...@gmail.com>.
Mark Miller wrote:
> Hmmm - you can probably get qsol to do it:
> http://myhardshadow.com/qsol. I think you can setup any token to
> expand to anything with a regex matcher and use group capturing in the
> replacement (I don't fully remember though, been a while since I've
> used it).
>
> So you could do a regex of something like : >=([0-9]+) and have it
> expand to [$1 rng Integer.Max] or something. Then handle the other cases.
>
> You also might come up with your own regex that you could apply to the
> standard Lucene query parser syntax, and pre-process using the same
> strategy.
>
>
Check the "New flexible query parser" thread in the java-dev,
This new parser if it is committed, has some of the features discussed
in this thread.
--
-Lafa
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
Hmmm - you can probably get qsol to do it: http://myhardshadow.com/qsol.
I think you can setup any token to expand to anything with a regex
matcher and use group capturing in the replacement (I don't fully
remember though, been a while since I've used it).
So you could do a regex of something like : >=([0-9]+) and have it
expand to [$1 rng Integer.Max] or something. Then handle the other cases.
You also might come up with your own regex that you could apply to the
standard Lucene query parser syntax, and pre-process using the same
strategy.
--
- Mark
http://www.lucidimagination.com
Michael McCandless wrote:
>
> Allahbaksh Mohammedali Asadullah wrote:
>
>> For example I want to search amount >= 15 rather than doing it
>> amount:[ 15] or something?
>>
>> Is there any open source queryparser which converts something like
>> amount >=15 into lucene number format query.
>
> I don't know of any effort to change Lucene's queryParser syntax to
> support this, nor an an existing open-source package to do so, but
> patches are always welcome!
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Allahbaksh Mohammedali Asadullah wrote:
> For example I want to search amount >= 15 rather than doing it
> amount:[ 15] or something?
>
> Is there any open source queryparser which converts something like
> amount >=15 into lucene number format query.
I don't know of any effort to change Lucene's queryParser syntax to
support this, nor an an existing open-source package to do so, but
patches are always welcome!
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Lucene 2.9
Posted by Allahbaksh Mohammedali Asadullah <Al...@infosys.com>.
Hi,
I was not aware of TrieRangeQuery but whether syntax for numberical query will change. For example I want to search
amount >= 15 rather than doing it amount:[ 15] or something?
Is there any open source queryparser which converts something like amount >=15 into lucene number format query.
Regards,
Allahbaksh
-----Original Message-----
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: Monday, March 09, 2009 4:26 PM
To: java-user@lucene.apache.org
Subject: RE: Lucene 2.9
> > Is there any plans to have simpler queries for Numbers and Data?
>
> With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's
> range querying is actually very strong, though you'd have to subclass
> QueryParser and override getRangeQuery to have it create TrieRangeQuery.
The additions for QueryParser to support this are done in Solr (because in
contrast to Lucene alone, Solr knows the datatype and encoding) of each
field: https://issues.apache.org/jira/browse/SOLR-940
You can do it in the same way. Maybe we should supply some "plugin" for the
QueryParser in TrieRange contrib?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Yonik Seeley wrote:
> On Mon, Mar 9, 2009 at 2:02 PM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>> Once added, something inside the index (a "write once" schema)
>> records
>> that this field is an IntField and then it's an error to ever use a
>> different type field by that same name.
>
> I dunno... coupling functionality to restrictions seems like it starts
> to erode some of Lucene's famous flexibility.
>
> Consider changing the type of a field from an int to a long... a
> reasonably smart app or user could delete and re-index documents with
> that field (it could be a small subset). Or even keep track of what
> documents had an int field vs a long field (via filters or something).
This example is the exception not the rule, though (simple things
should be
simple... complex things should be possible). I think we should make
this case possible, but it need not be simple.
EG one could always still use an untyped field to do expert things.
Whereas we have the reverse today: if I simply want to add a number
field to my docs, and search it by range and sort by it, it's far from
simple.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Mon, Mar 9, 2009 at 2:02 PM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Once added, something inside the index (a "write once" schema) records
> that this field is an IntField and then it's an error to ever use a
> different type field by that same name.
I dunno... coupling functionality to restrictions seems like it starts
to erode some of Lucene's famous flexibility.
Consider changing the type of a field from an int to a long... a
reasonably smart app or user could delete and re-index documents with
that field (it could be a small subset). Or even keep track of what
documents had an int field vs a long field (via filters or something).
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
markharw00d wrote:
> >>(a "write once" schema)
>
> I like this idea. Enforcing consistent field-typing on instances of
> fields with the same name does not seem like an unreasonable
> restriction - especially given the upsides to this.
And also when it's "opt-in", ie, you can continue to use untyped/
unrestricted fields.
> One note of caution is that users may be tempted to store primary
> keys as ints or longs and incur the overhead of trie encoding when
> there is no use case for range queries on these types of fields.
>
> I've often thought of field types as belonging to these broad
> categories (rather than ints/strings/longs etc):
> 1) Quantifiers - used to express numeric quantities that are often
> queried in ranges e.g. price, datetime, longitude
> 2) Identifiers - designed to be unique e.g. urls, primary keys
> 3) Controlled vocabularies - enums e.g. male/female or public/private
> 4) Uncontrolled vocabularies - e.g free text
>
> "Ints" can be used to represent types 1 to 3 but the practical uses
> of them differ (range queries vs straight-look ups vs faceted groups)
> It seems like the likely use cases are more important than the raw
> data format (int vs long etc)
I like working by usage instead of underlying type, and I like this
breakdown. It would allow us to do a better job defaulting the
settings for these fields types.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by markharw00d <ma...@yahoo.co.uk>.
>>(a "write once" schema)
I like this idea. Enforcing consistent field-typing on instances of
fields with the same name does not seem like an unreasonable restriction
- especially given the upsides to this.
It doesn't dispense with all the full schema logic in Solr but seems
like a useful baseline for supporting basic numeric field types well in
Lucene.
One note of caution is that users may be tempted to store primary keys
as ints or longs and incur the overhead of trie encoding when there is
no use case for range queries on these types of fields.
I've often thought of field types as belonging to these broad categories
(rather than ints/strings/longs etc):
1) Quantifiers - used to express numeric quantities that are often
queried in ranges e.g. price, datetime, longitude
2) Identifiers - designed to be unique e.g. urls, primary keys
3) Controlled vocabularies - enums e.g. male/female or public/private
4) Uncontrolled vocabularies - e.g free text
"Ints" can be used to represent types 1 to 3 but the practical uses of
them differ (range queries vs straight-look ups vs faceted groups)
It seems like the likely use cases are more important than the raw data
format (int vs long etc)
Cheers
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
mark harwood wrote:
> Time for some standardised index metadata?
OK, thinking out loud...
What if we created IntField, subclassing Field. It holds a single
int, and you can add it to Document just like any other field.
Once added, something inside the index (a "write once" schema) records
that this field is an IntField and then it's an error to ever use a
different type field by that same name.
This field would have int(number)-specific options, with good
defaults. So eg one option would turn on Trie* indexing (would
default to on). You could set zero padding, etc.
(And ShortField, LongField, FloatField, DoubleField, etc.; they could
all inherit from NumericField)
Couldn't we do this incrementally today? It should be fully
back-compatible...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
mark harwood wrote:
> This trie/parser issue is an example of a broader issue for me.
Yeah I agree.
There was also a new Document impl attached in Jira somewhere to more
strongly type fields (can't find it now), ie IntField, DateField, etc.
And it also ties into refactoring AbstractField/Fieldable/Field.
And eg KinoSearch has a fixed schema I believe.
I'm just wondering if we can somehow make incremental progress
here... it's ashame that most people who use Lucene will simply use
RangeQuery in its current incarnation since that's the "default".
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by mark harwood <ma...@yahoo.co.uk>.
>>Maybe we could do something similar to declare that agiven field uses Trie*, and with what datatype.
With the current implementation you can at least test for the presence of a field called:
[fieldName]#trie
..which tells you some form of trie is used but could be extended to include precision step value e.g.
[fieldName]#trie_8
But - overall, I can't help but feel we will struggle to offer facilities like this when there is a lack of a formal schema for Lucene indexes.
Solr obviously includes some form of index definition - my Lucene-based apps tend to use a custom config and Luke could certainly benefit from some form of definition stored with the index.
Time for some standardised index metadata?
This trie/parser issue is an example of a broader issue for me.
Mark
----- Original Message ----
From: Michael McCandless <lu...@mikemccandless.com>
To: java-user@lucene.apache.org
Sent: Monday, 9 March, 2009 13:10:32
Subject: Re: Lucene 2.9
Uwe Schindler wrote:
>> Or perhaps we should move Trie* into core Lucene, and then build a
>> real (ootb) integration with QueryParser.
>
> The problem is that the query parser does not know if a field is encoded as
> trie or is just a normal text token. Furthermore, the new trie API does not
> differentiate between dates, doubles, longs (same for 32bit) because every
> trie field is identical (it is the application's task to keep track on the
> encoding when indexing and searching, TrieRange only supports the conversion
> of these data types to sortable integers), but the "datatype" itself is not
> stored in index. Solr has support for this in its "schema", but for Lucene
> all fields are identical. For the query parser there is no possibility to
> differentiate between a long, double or date.
Could we add APIs to QueryParser so the application can state the disposition
toward certain fields?
EG QueryParser now tries to guess whether a range query's upper/lower bound
should be parsed as dates, and there are methods exposed to set the resolution
on a per-field basis. Maybe we could do something similar to declare that a
given field uses Trie*, and with what datatype.
Just thinking aloud really... but since we haven't yet released Trie*, now (for 2.9)
is a good time to think hard about how we expose/integrate it... and making it
easier to use ootb seems important.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Mon, Mar 9, 2009 at 8:10 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> Could we add APIs to QueryParser so the application can state the
> disposition
> toward certain fields?
overriding QueryParser.getRangeQuery() seems the most powerful and
flexible (and it's already there).
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Lucene 2.9
Posted by Allahbaksh Mohammedali Asadullah <Al...@infosys.com>.
Hi,
It is really nice idea to have something like if I am doing a query like amount >15 something depending upon the field and do query parsing. Basically we need have pluggable query parser which can convert different queries like amount >15 to lucene specified query.
That is what I think. I am using Lucene for long time and love to see this kind of stuff. Though Minin provided this I am not really happy with performance nor the GPL and probably it is love toward using things from Apache Foundation (Tomcat, Lucene, Common, HTTPD etc) .
Regards,
Allahbaksh Mohammedali Asadullah,
http://allahbaksh.blogspot.com
Starting a startup is hard, but having a 9 to 5 job is hard too, and in some ways a worse kind of hard.
-----Original Message-----
From: Michael McCandless [mailto:lucene@mikemccandless.com]
Sent: Monday, March 09, 2009 6:41 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene 2.9
Uwe Schindler wrote:
>> Or perhaps we should move Trie* into core Lucene, and then build a
>> real (ootb) integration with QueryParser.
>
> The problem is that the query parser does not know if a field is
> encoded as
> trie or is just a normal text token. Furthermore, the new trie API
> does not
> differentiate between dates, doubles, longs (same for 32bit) because
> every
> trie field is identical (it is the application's task to keep track
> on the
> encoding when indexing and searching, TrieRange only supports the
> conversion
> of these data types to sortable integers), but the "datatype" itself
> is not
> stored in index. Solr has support for this in its "schema", but for
> Lucene
> all fields are identical. For the query parser there is no
> possibility to
> differentiate between a long, double or date.
Could we add APIs to QueryParser so the application can state the
disposition
toward certain fields?
EG QueryParser now tries to guess whether a range query's upper/lower
bound
should be parsed as dates, and there are methods exposed to set the
resolution
on a per-field basis. Maybe we could do something similar to declare
that a
given field uses Trie*, and with what datatype.
Just thinking aloud really... but since we haven't yet released Trie*,
now (for 2.9)
is a good time to think hard about how we expose/integrate it... and
making it
easier to use ootb seems important.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Uwe Schindler wrote:
>> Or perhaps we should move Trie* into core Lucene, and then build a
>> real (ootb) integration with QueryParser.
>
> The problem is that the query parser does not know if a field is
> encoded as
> trie or is just a normal text token. Furthermore, the new trie API
> does not
> differentiate between dates, doubles, longs (same for 32bit) because
> every
> trie field is identical (it is the application's task to keep track
> on the
> encoding when indexing and searching, TrieRange only supports the
> conversion
> of these data types to sortable integers), but the "datatype" itself
> is not
> stored in index. Solr has support for this in its "schema", but for
> Lucene
> all fields are identical. For the query parser there is no
> possibility to
> differentiate between a long, double or date.
Could we add APIs to QueryParser so the application can state the
disposition
toward certain fields?
EG QueryParser now tries to guess whether a range query's upper/lower
bound
should be parsed as dates, and there are methods exposed to set the
resolution
on a per-field basis. Maybe we could do something similar to declare
that a
given field uses Trie*, and with what datatype.
Just thinking aloud really... but since we haven't yet released Trie*,
now (for 2.9)
is a good time to think hard about how we expose/integrate it... and
making it
easier to use ootb seems important.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Monday, March 09, 2009 12:51 PM
> To: java-user@lucene.apache.org
> Subject: Re: Lucene 2.9
>
>
> Uwe Schindler wrote:
>
> >>> Is there any plans to have simpler queries for Numbers and Data?
> >>
> >> With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's
> >> range querying is actually very strong, though you'd have to subclass
> >> QueryParser and override getRangeQuery to have it create
> >> TrieRangeQuery.
> >
> > The additions for QueryParser to support this are done in Solr
> > (because in
> > contrast to Lucene alone, Solr knows the datatype and encoding) of
> > each
> > field: https://issues.apache.org/jira/browse/SOLR-940
> >
> > You can do it in the same way. Maybe we should supply some "plugin"
> > for the
> > QueryParser in TrieRange contrib?
>
> +1
>
> Or perhaps we should move Trie* into core Lucene, and then build a
> real (ootb) integration with QueryParser.
The problem is that the query parser does not know if a field is encoded as
trie or is just a normal text token. Furthermore, the new trie API does not
differentiate between dates, doubles, longs (same for 32bit) because every
trie field is identical (it is the application's task to keep track on the
encoding when indexing and searching, TrieRange only supports the conversion
of these data types to sortable integers), but the "datatype" itself is not
stored in index. Solr has support for this in its "schema", but for Lucene
all fields are identical. For the query parser there is no possibility to
differentiate between a long, double or date.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Uwe Schindler wrote:
>>> Is there any plans to have simpler queries for Numbers and Data?
>>
>> With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's
>> range querying is actually very strong, though you'd have to subclass
>> QueryParser and override getRangeQuery to have it create
>> TrieRangeQuery.
>
> The additions for QueryParser to support this are done in Solr
> (because in
> contrast to Lucene alone, Solr knows the datatype and encoding) of
> each
> field: https://issues.apache.org/jira/browse/SOLR-940
>
> You can do it in the same way. Maybe we should supply some "plugin"
> for the
> QueryParser in TrieRange contrib?
+1
Or perhaps we should move Trie* into core Lucene, and then build a
real (ootb) integration with QueryParser.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
> > Is there any plans to have simpler queries for Numbers and Data?
>
> With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's
> range querying is actually very strong, though you'd have to subclass
> QueryParser and override getRangeQuery to have it create TrieRangeQuery.
The additions for QueryParser to support this are done in Solr (because in
contrast to Lucene alone, Solr knows the datatype and encoding) of each
field: https://issues.apache.org/jira/browse/SOLR-940
You can do it in the same way. Maybe we should supply some "plugin" for the
QueryParser in TrieRange contrib?
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Allahbaksh Mohammedali Asadullah wrote:
> When is Lucene 2.9 due? I am eagerly waiting for the new lucene to
> come.
There have been some discussions on java-dev, but there's no clear
consensus/date yet. We do have quite a few Jira issues marked as 2.9
at this point, which we need to make progress on or push out:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310110&fixfor=12312682
> As I compared Lucene with Minion I think Minion offers very rich
> capabilities like easier range query etc.
Can you provide some detail on what's different about range queries,
or any other differences? Is it the lack of numeric operators (<, <=,
>, >=, !=) via QueryParser? Minion definitely looks like a neat
search engine.
> Is there any plans to have simpler queries for Numbers and Data?
With the recent addition of TrieRangeQuery (in 2.9), I think Lucene's
range querying is actually very strong, though you'd have to subclass
QueryParser and override getRangeQuery to have it create TrieRangeQuery.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org