[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722305#action_12722305
]
Uwe Schindler commented on LUCENE-1701:
---------------------------------------
Yes, it would work this way. This only would violate Yoniks complaints about
not miximg Trie too much into the other code, but this is already done because
of this StopFillCacheException usage. When we do LUCENE-831, this should be
thought about, too.
I would make the core parsers public to enable users to have full control (on
the other hand I could now hide also the trie parsers). But this is a bad
approach, wherever automatisms are envolved, oneshould always have the
possibility to fix to one parser. And why do we have the SortField/FieldCache
accessors with parser parameter, when you cannot even use the default ones?
P.S.: About payloads & positions and the need for extra parameters to the
parser: After adding support for positions or payloads to encode the highest
precision, there is still no need for an extra SortField/Parser class or
factory. The future "ValueSource" starts to decode the values until a change in
shift occurs. This first shift is for sure the highest precision (because of
term ordering), if it is 0, its like now (no payloads/prositions); if the first
visible shift>0, payloads/positions were used and the numbero of bits there is
also known.
> 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: LUCENE-1701-test-tag-special.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, 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
