[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721946#action_12721946
]
Uwe Schindler commented on LUCENE-1701:
---------------------------------------
bq. ut any new field cache API should be powerful enough to handle trie through
the normal APIs that anyone else would have to go through when implementing
their own field type
This is true, the LUCENE-831 patch contains a TrieValueSource for that (but it
does not apply anymore, as contrib/search/trie is no longer available). Because
of this, it can be implemented very cleanly.
For easy usage, I would simply suggest to have the parsers for the current
plain text and trie field cache implementation public available as singletons,
very simple and hurts nobody. I will post a patch for the whole case soon.
NumericField will be tested in the NumericRangeQuery index creation (which is
currently very ugly, like meikes comments about the code and reusing
Fields/TokenStreams, with NumericField it looks like any other index code).
For Solr (SOLR-940), there is not need to use NumericField (which is just a
helper), the code of TrieField can stay as it is, only some renamings and so
on. It just presents a TokenStream to the underlying Solr indexer, as before.
> 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
