lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woody Anderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2544) Add 'divisor' to NumericField, allows for easy storage of full precision data, but indexing *starting* at lower precision.
Date Tue, 21 Sep 2010 18:07:34 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message