[ https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721827#action_12721827 ]
Uwe Schindler edited comment on LUCENE-1701 at 6/19/09 8:50 AM: ---------------------------------------------------------------- But the same problem like with NumericTokenStream affects also NumericField, because of type safety it will only work with a setXxxValue (if not factory), e.g. {code} doc.add(new NumericField("price", precisionStep).setFloatValue(15.50f)); {code} This code is not shorter than: {code} doc.add(NumericUtils.newFloatField("price", precisionStep, 15.50f)); {code} Additionally with LUCENE-1699, we could also add Field.Store.XXX to the factory/ctor. OK, the factory solution has the problem, that you cannot reuse the field for effectiveness, so this is an argument *for* the extra class, that has setXxXValue(). For SortField: The factory code inside NumericUtils is only one Line, you only create a conventional SortField with a specific parser. If we do not want to have the factory in NumericUtils, I could also add an additional ctor option to the normal sortfield (which is still there: it takes the parser, LUCENE-1478). When all parsers are central in the FieldCache, one can create a SortField with one line of code (the current factory demonstrates this). was (Author: thetaphi): But the same problem like with NumericTokenStream affects also NumericField, because of type safety it will only work with a setXxxValue (if not factory), e.g. {code} doc.add(new NumericField("price", precisionStep).setFloatValue(15.50f)); {code} This code is not shorter than: {code} doc.add(NumericUtils.newFloatField("price", precisionStep, 15.50f)); {code} Additionally with LUCENE-1699, we could also add Field.Store.XXX to the factory/ctor. For SortField: The factory code inside NumericUtils is only one Line, you only create a conventional SortField with a specific parser. If we do not want to have the factory in NumericUtils, I could also add an additional ctor option to the normal sortfield (which is still there: it takes the parser, LUCENE-1478). When all parsers are central in the FieldCache, one can create a SortField with one line of code (the current factory demonstrates this). > 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 > > > 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