lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-1701) Add NumericField and NumericSortField, make plain text numeric parsers public in FieldCache, move trie parsers to FieldCache
Date Fri, 19 Jun 2009 21:20:07 GMT


Michael McCandless commented on LUCENE-1701:

bq. That is what I was talking about all the time!

Eh, yeah... somethings things just need a good hashing out!

2.9 is really shaping up to be an awesome release...

bq. But this is all not really the best solution. It is too bad, that LUCENE-831 (not in current
form, it is just not discussed to the end) is not to be included into 2.9.

Progress not perfection!

bq. I know we will have to stick with parsers until end of days, because the new ValueSource
staff and Uninverters was not introduces early enough to be removed with 3.0.

Well we are discussing relaxing the back-compat policy... so maybe
earlier than "end of days".

bq. And Trie fields with positions/payloads would never work with current FieldCache, so I
need no factories.

We'll cross that bridge when we get there...

bq. So this would be postponed until this is done. Then we could have a ValueSource for trie
fields, where you could add these magic stuff like payloads and so on. But until this comes
to reality (including CSF), the static parsers is all we have until now and is best placed
in FieldCache (because of the strong linkage with this ugly exception to be hidden to the

I agree.

bq. Earwin, Yonik: I know TrieRange is only one implementation of the whole numeric problem,
but none of you ever presented your implementation to the public. This is the best we have
now, its included into core and everybody is happy. If you have a better private implementation,
you can still use it!

We shouldn't weaken trie's integration to core just because others
have private implementations.  What's important is that we don't
weaken those private implementations with trie's addition, and I don't
think our approach here has done that.

> Add NumericField and NumericSortField, make plain text numeric parsers public in FieldCache,
move trie parsers to FieldCache
> ----------------------------------------------------------------------------------------------------------------------------
>                 Key: LUCENE-1701
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index, Search
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>         Attachments:
> In discussions about LUCENE-1673, Mike & me wanted to add a new NumericField to o.a.l.document
specific for easy indexing. An alternative would be to add a NumericUtils.newXxxField() factory,
that creates a preconfigured Field instance with norms and tf off, optionally a stored text
(LUCENE-1699) and the TokenStream already initialized. On the other hand NumericUtils.newXxxSortField
could be moved to NumericSortField.
> I and Yonik tend to use the factory for both, Mike tends to create the new classes.
> Also the parsers for string-formatted numerics are not public in FieldCache. As the new
SortField API (LUCENE-1478) makes it possible to support a parser in SortField instantiation,
it would be good to have the static parsers in FieldCache public available. SortField would
init its member variable to them (instead of NULL), so making code a lot easier (FieldComparator
has this ugly null checks when retrieving values from the cache).
> Moving the Trie parsers also as static instances into FieldCache would make the code
cleaner and we would be able to hide the "hack" StopFillCacheException by making it private
to FieldCache (currently its public because NumericUtils is in o.a.l.util).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message