[
https://issues.apache.org/jira/browse/LUCENE-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913133#action_12913133
]
Woody Anderson commented on LUCENE-2544:
----------------------------------------
I really do understand the difference between Field the instance object, and a
field in the index. I use cap F for the java class and lowercase for the index.
You can accomplish this with two NFs, but you can also implement NumericField
with a series of "new Field()" using the same name as well. But, you don't do
this, b/c it's much more convenient to have it bundled up in a nice concise
form.
There is (admittedly, from my perspective) one issue with this kind of feature.
It's that the divisor must be known and kept track of by the lucene user during
query parsing and during term-enum inspection if they are doing that sort of
thing. The current QueryParser uses a map of field to DateTools.Resolution,
which this mechanism would effectively mimic. Though it would produce
NumericField formatted tokens in the index rather than date strings, which can
often be an advantage for ranges etc. The fact that it also provides numeric
resolution for any numeric field is a bonus, but it would involve some change
to the QueryParser to correctly handle this, as it currently does not handle
querying any field indexed as NumericField. Both this edit and DateTools have
the same drawbacks for term-enum inspection (facets etc), so clearly the
responsibility for handling that lies with the user of lucene already. I have a
schema at parse/inspect time, so i had overlooked this issue.
At any rate, I still don't get what you consider confusing about this
functionality. DateTools.Res shows clear use case, modern NumericField features
for fast ranges etc. is often a clear improvement over string date tokens at
any resolution. And wrapping it up into the single existing class is just
easier to use than requiring multiple NF objects be added to the document.
Unless you advocated that NF be implemented as a static utility class that
injected multiple Field objects into the Document, i'm not sure why this
consolidation goes against the grain.
> Add 'divisor' to NumericField, allows for easy storage of full precision
> data, but indexing *starting* at lower precision.
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2544
> URL: https://issues.apache.org/jira/browse/LUCENE-2544
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Affects Versions: 3.0.2
> Reporter: Woody Anderson
> Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2544.patch
>
>
> In some cases, we want to index a timestamp or some other high precision
> numeric at a much lower precision, but we still want to store the full
> precision data.
> Rather than have to do this with two Field objects in the Document, it'd be
> easier to provide NumericField with a divisor as well as prevision step. The
> divisor would apply before beginning the trie logic.
> most often, this is a divide by 1, but that will happen only during the
> constructor or setXXXValue() in NumericTokenStream.
> I have the patch for this, or i will after i isolate it.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
