[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721914#action_12721914
]
Uwe Schindler commented on LUCENE-1701:
---------------------------------------
Yonik, I will explain my intention:
The real numeric parsing is always done in NumericUtils, as for conventional
FieldCache the real parsing is done in Integer.parseInt() and so on.
Specific to the FieldCache is the Parser interface. This parser interface is a
java interface specific to FieldCache. FieldCache currently has (private)
static parser instances for Number.toString()-type fields. These parser are
simple 5-liners and singletons. For trie fields, this is the same, the static
parser instances (also singletons) should be moved also to FieldCache, after
that both as public constants (like Mike said: PLAIN_TEXT_INT_PARSER and
NUMERIC_INT_PARSER).
Currently for Trie fields there is a ugly hack in FieldCache, that stops
parsing, when a term with lower precision is reached (as trie terms are ordered
with highest precision first, the cache for a field is filled, when the first
lower-precision term comes). Because of this, the trie parsers throw a
unchecked StopFillCacheException to stop the iteration of TermEnum/TermDocs in
the Uninverter. This is just a hack and because of package differences this
FieldCache-internal exception is made public (see Javadocs). When moving the
parser interfaces to FieldCace, this Exception can be hidden again and made
private to the FieldCache implementation (until we have the better univerters
some time in future, see LUCENE-831). NumericUtils then will only just export a
method to get the shift value out of a encoded string (which I forgot to add in
LUCENE-1673 when removing ShiftAttribute).
Trie field parsing does not depend on Trie-specific flags, precisionStep is not
needed, so the parsers are real singletons.
SortFields can then simply created in the Following way: new SortField(field,
FieldCache.PLAIN_TEXT_INT_PARSER) for a conventional int field (like with
SortField.INT) or new SortField(field, FieldCache.NUMERIC_INT_PARSER). giving a
NULL parser still does the same as before, it uses
FieldCache.PLAIN_TEXT_INT_PARSER implicitely.
> 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
