lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3001) Add TrieFieldHelper lucene so we can write solr compatible Trie* fields w/o solr dependency
Date Tue, 29 Mar 2011 20:44:05 GMT


Uwe Schindler commented on LUCENE-3001:

The problem with the binary encoding in Lucene is/was: Lucene lacks a schema, so you cannot
use the Document.get() methods on the search results to "easy" get the field. This is why
the NumericField (which is *not* returned on retrieving search results) was simply encoded
as String values. The stored field contents are not really relevant to search, the toString()
was only added to NumericField to support an easy to use encoding.

The problem is again compatibility: Lucene must still support the old encoding and lots of
software relies on it (because you can simply use Document.get() on search results). So I
propose to extend NumericField to have it's own Field.Store enum (that provides both stored
field encodings). The default precisionStep should not be changed (and solr should also switch
to 4 as default).

Then somebody can use: new NumericField(precisionStep, NumericField.Store.STRING / NumericField.Store.BINARY,...).
Solr can then also return NumericField instances in it getFieldable() method. For decoding
search results some wrapper must be provided to Lucene (until we have a schema).

This is just a starting point for discussion.

> Add TrieFieldHelper lucene so we can write solr compatible Trie* fields w/o solr dependency
> -------------------------------------------------------------------------------------------
>                 Key: LUCENE-3001
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>            Reporter: Ryan McKinley
>            Priority: Minor
>         Attachments: LUCENE-3001-TrieFieldHelper.patch
> The solr support for numeric fields writes the stored value as binary vs the lucene NumericField
> We should move this logic to a helper class in lucene core so that libraries that do
not depend on solr can write TrieFields that solr can read.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message