contrib in revision 786474
Thanks for all your help! I will now open another issue for the remaining
(optional) tasks
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene
the parsers to FieldCache and make the plain-text-number parsers public
there, too.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New
can separately tweak the javadocs...
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
for cutting over contrib/spacial to
NumericUtils
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components
in stored fields file
and the index format is unchanged.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
back-compat issues, so it could be
added any time - no need to link it to this issue or to rush it.
I think the same, I should first resolve this and open some more issues :-)
Move TrieRange to core
--
Key: LUCENE-1673
URL: https
of these (NumericField, NumericSortField)
are important to do for 2.9. Maybe others (adding support for the
missing numeric types (byte short)) can wait.
Let's wrap this one up and move onto the next ones ;)
Move TrieRange to core
--
Key: LUCENE-1673
URL
a short note to package.html in
analysis and search.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components
section
detailing how it works, what precisionStep means (and tradeoffs of high/low
values for it), the reference to the full paper, etc.
But we can iterate on the javadocs in the separate issue, too.
Move TrieRange to core
--
Key: LUCENE-1673
would return a
NumericField.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects
:00 on the following day exclusive.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
on the day to 0:00 on the following day exclusive.
Couldn't we have a NumericTermQuery for such cases? You have the full
precision term in the index...
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse
downto the
millisecond). The important thing is: the lower precision terms are not at
common date boundaries.
Because of this different use cases, in my opinion, DateTools has its usage.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https
of fields... they aren't coupled now except when the generic format
of the index changes (like omitNorms, omitTf, indexed, etc).
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
things are lost from your index time doc (a well known issue at this
point!), but I don't think we should intentionally make that behavior
even more buggy, if we can help it...
Move TrieRange to core
--
Key: LUCENE-1673
URL: https
in Lucene...
changing that and encoding types into the index deserves it's own issue and
discussion (and something big like that doesn't seem to belong in 2.9 which is
winding down).
Move TrieRange to core
--
Key: LUCENE-1673
URL: https
everything else does in Lucene...
changing that and encoding types into the index deserves it's own issue and
discussion (and something big like that doesn't seem to belong in 2.9 which is
winding down).
Move TrieRange to core
--
Key: LUCENE-1673
and put it in contribs. If it's hard to build - Lucene core is to
blame, it's not extensible enough. From my experience, for that purporse it's
okay as it is.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse
to be openend after this.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects Versions: 2.9
these numeric types too...).
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects
it util seems OK, since it's used by analysis searching.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components
the right parser?
A factory method TrieUtils.getSortField() could also return the right SortField.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
, but as the code was not yet released (in Lucene), the Lucene
version should not use NumberUtils at all.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
() in NumericTokenStream? This makes
it really easy to index.
The only good thing of NumericField would be the possibility to automatically
disable TF and Norms per default when indexing.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org
in complete, its really useless. Maybe, I
add a getShift() method to NumericUtils, that returns the shift value of a
Token/String. See java-dev mailing with Yonik.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira
be the possibility to
automatically disable TF and Norms per default when indexing.
Consumability (good defaults)! (And also not having to know that you
must go and get a tokenStream from NumericUtils).
Move TrieRange to core
--
Key: LUCENE-1673
Michael McCandless (JIRA) wrote:
We're forking off new 2.9 issues left and
right here!!
Evil :) You guys are like small team working against me.
We still have 29+- issue to wrap up though, so probably plenty of time.
I hope we can set a rough target date soon though - it really feels like
On Mon, Jun 15, 2009 at 4:42 PM, Mark Millermarkrmil...@gmail.com wrote:
Remember the last time we started to push for 2.9 in Dec/Jan :)
Yes this is very much on my mind too!!
So maybe, it's a race between the trie* group of issues, and the other 28 ;)
Mike
PM
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-1673) Move TrieRange to core
On Mon, Jun 15, 2009 at 4:42 PM, Mark Millermarkrmil...@gmail.com wrote:
Remember the last time we started to push for 2.9 in Dec/Jan :)
Yes this is very much on my mind too!!
So
about it
- [unneeded SortField factory, parsers] - extra issue, maybe after 3.0
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New
-compat issues, so it could be added
any time - no need to link it to this issue or to rush it.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue
, as TRIE no longer used) and
the parser instances can be added to FieldCache.
For indexing or querying it is not required for end users, one can use
NumericTokenStream and NumericRangeQuery for all his needs.
So NumberUtils is more internal than before.
Any thoughts?
Move TrieRange to core
encoding name from TrieUtils)
- the default parsers (private) in FieldCache renaming to also PlainText* (but
accessible)
- add TrieUtils.XxxParser to FieldCache (but accessible)
Move TrieRange to core
--
Key: LUCENE-1673
URL: https
(private) in FieldCache renaming to also PlainText* (but
accessible)
- add TrieUtils.XxxParser to FieldCache (but accessible)
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
changes here.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects Versions: 2.9
an
analysis.numeric package?
As a general comment, moving TrieRange to core should be moving it to the core
and perhaps renaming the classes if we can think of a better name. Some of the
other stuff belongs in a different issue.
Move TrieRange to core
--
Key
, moving TrieRange to core should be moving it to the
core and perhaps renaming the classes if we can think of a better name. Some of
the other stuff belongs in a different issue.
I think this is correct. I will post a patch soon, that leaves TrieUtils alive.
Move TrieRange to core
and
friends).
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects Versions: 2.9
people from doing things like
new NumericRangeQuery(field,precStep,new Long(val1),new Float(val2)) which may
lead to undefined behaviour. The second problem is missing type safety with
auto-boxing in Java 5.
Move TrieRange to core
--
Key: LUCENE-1673
)) which may
lead to undefined behaviour. The second problem is missing type safety with
auto-boxing in Java 5.
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene
of
java.lang.Number? Because type safety to prevent people from doing things like
new NumericRangeQuery(field,precStep,new Long(val1),new Float(val2)) which may
lead to undefined behaviour. The second problem is missing type safety with
auto-boxing in Java 5.
Move TrieRange to core
. NumericRangeQuery.newFloatRange(Float a, Float b, precisionStep) and so on.
Could we also do this for a term range? Then, we could have a single
RangeQuery that rewrites to the right impl based on what kind of range you are
doing?
(And in fact it could fold in FieldCacheRangeFilter too).
Move TrieRange to core
, with this
change. EG TermRangeQuery... to emphasize that you use it for
non-numbers. The javadocs of TermRangeQuery should point to
Int/LongRangeQuery as strongly preferred for numeric ranges.
Cool. For the others, too (FieldCacheRangeQuery).
{quote}
Yes.
Move TrieRange to core
, with this
change. EG TermRangeQuery... to emphasize that you use it for
non-numbers. The javadocs of TermRangeQuery should point to
Int/LongRangeQuery as strongly preferred for numeric ranges.
Cool. For the others, too (FieldCacheRangeQuery).
{quote}
Yes.
Move TrieRange to core
http://www.thetaphi.de
eMail: u...@thetaphi.de
_
From: Jason Rutherglen [mailto:jason.rutherg...@gmail.com]
Sent: Tuesday, June 09, 2009 8:48 PM
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-1673) Move TrieRange to core
I wonder if we could handle this by adding
compile, because the setValue method is not
available for TokenStream; the stream should be defined as
LongTrieTokenStream, I think?; same with IntTrieTokenStream)
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira
}
Cool. For the others, too (FieldCacheRangeQuery).
There is a lot more to decide, I will keep this issue open a little bit before
starting to work to collect ideas!
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New Feature
Components: Search
Affects Versions: 2.9
Reporter
, you won't be bound by any other
back-compat policies besides common sense. :)
Move TrieRange to core
--
Key: LUCENE-1673
URL: https://issues.apache.org/jira/browse/LUCENE-1673
Project: Lucene - Java
Issue Type: New
putting everything in o.a.l.trie .
I'd prefer to have explicit class names containing Long, Int etc, and also
containing Trie.
I don't know the details of the tokenizing, but AbstractTrieField sounds just
right.
Move TrieRange to core
--
Key: LUCENE
Hi,
it was discussed now many times on this list, but I did not get a solution,
if we should include TrieRange into the core or not.
When thinking about it and looking in the latest developments about
TrieRange (TokenStreams for indexing), I plan to do the following:
a) Put the classes into the
Uwe Schindler wrote:
MultiTermQuery has in its protected getEnum() returning FilteredTermEnum.
For TrieRange, the return should be changed to TermEnum, it is not needed to
have a FilteredTermEnum (FilteredTermEnum is only an implementation, the
method should return an abstract TermEnum). If this
MultiTermQuery has in its protected getEnum() returning
FilteredTermEnum.
For TrieRange, the return should be changed to TermEnum, it is not
needed to
have a FilteredTermEnum (FilteredTermEnum is only an implementation, the
method should return an abstract TermEnum). If this is fixed, I
On Mon, Apr 13, 2009 at 12:05 PM, Uwe Schindler u...@thetaphi.de wrote:
For me it would not be a problem, I would use a FilteredTermEnum and
subclass it, but would only implement next() and the other abstract methods
would be dummies (including difference() returning 1.0f). Only the enum and
For me it would not be a problem, I would use a FilteredTermEnum and
subclass it, but would only implement next() and the other abstract
methods
would be dummies (including difference() returning 1.0f). Only the enum
and
the term should have a protected access or a getter in this class.
(resending msg from earlier today during @apache mail outage -- i didn't
get a copy from the list, so i'm assuming no one did)
: Date: Fri, 20 Mar 2009 16:51:05 -0700 (PDT)
:
: : I think we should move TrieRange* into core before 2.9?
:
: -0
:
: I think we should try to move more things *out
If so... maybe we could extend FieldCache's parser to allow it to
stop-early? Ie it'd get the TermEnum, iterate through all the full
precision terms first, asking your parser to convert to long/int,
and then when your parser sees the very first not-full-precision
term, it tells
Uwe Schindler u...@thetaphi.de wrote:
My problem is: In my opinion, this is all to complicated and nasty
and bad API design.
One nice, but hackish approach would be to define
FieldCache.StopFillCacheException extends RuntimeException and throw
this inside the parse function, if a trie value
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler more scalable way to index numeric fields that you
intend to sort and/or do range
On Mar 18, 2009, at 13:01, Michael McCandless
luc...@mikemccandless.com wrote:
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler
On Wed, Mar 18, 2009 at 23:08, Andi Vajda va...@osafoundation.org wrote:
On Mar 18, 2009, at 13:01, Michael McCandless luc...@mikemccandless.com
wrote:
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe Yonik did
lots
...@thetaphi.de
-Original Message-
From: Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Wednesday, March 18, 2009 9:02 PM
To: java-dev@lucene.apache.org
Subject: move TrieRange* to core?
I think we should move TrieRange* into core before 2.9?
It's received alot
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler more scalable way to index numeric fields that you
intend to sort and/or do
Uwe Schindler wrote:
I would be happy with a renaming to NumberRangeFilter, but trie
should appear somewhere in the docs.
I like this approach (and referencing the original paper); I think
it's important the javadocs give enough detail about how it works so
that one can understand the big
Uwe Schindler wrote:
I have no problem with it! Thanks!
What I would like to be fixed before moving it to core is the fact
that a
additional helper field is needed for the trie values. If everything
could
be in one field and the field is still sortable, it would be fine.
For that,
the
Michael McCandless luc...@mikemccandless.com wrote:
Though, won't this make loading the field cache more costly since
you'll iterate through many more terms?
Or... do the full precision fields always order above all lower
precision fields across all docs?
If so... maybe we could extend
Though, won't this make loading the field cache more costly since
you'll iterate through many more terms?
Or... do the full precision fields always order above all lower
precision fields across all docs?
The highest precision terms have a shift value of 0. As the first char of
the encoded
Uwe Schindler u...@thetaphi.de wrote:
If so... maybe we could extend FieldCache's parser to allow it to
stop-early? Ie it'd get the TermEnum, iterate through all the full
precision terms first, asking your parser to convert to long/int,
and then when your parser sees the very first
68 matches
Mail list logo
