[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722002#action_12722002
]
Uwe Schindler commented on LUCENE-1701:
---------------------------------------
That is what I was talking about all the time!
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. 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. And Trie fields with positions/payloads would
never work with current FieldCache, so I need no factories.
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 outside).
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!
> Add NumericField and NumericSortField, make plain text numeric parsers public
> in FieldCache, move trie parsers to FieldCache
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1701
> URL: https://issues.apache.org/jira/browse/LUCENE-1701
> 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: NumericField.java
>
>
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
