DocValues was designed to support unanalyzed types
originally. I don't know that code, but given my respect
for the people who wrote I'd be amazed if there weren't
very good reasons this is true. I suspect your work-around
is going to be "surprising".

And have you tested your change at scale? I suspect
searching won't scale well.

bq:  I need a case-insensitive search for a relatively short string
and at the same time, I need faceting on the original string

There's no reason at all to change code to do this. Just use a copyField.
The field that's to be faceted on is a "string" type with docValues=true, and
the searchable field is some text type with the appropriate analysis chain.

This doesn't really make much difference memory wise since the indexing
and docValues are separate in the first place. I.e. if I specify
indexed=true and docValues=true I get _two_ sets of date indexed.

Best,
Erick

On Tue, Jan 26, 2016 at 8:50 AM, Harry Yoo <hyunat...@gmail.com> wrote:
> Hi, I actually needed this functionality for a long time and I made up an 
> extended data type to work around.
>
> In my use case, I need a case-insensitive search for a relatively short 
> string and at the same time, I need faceting on the original string. For 
> example, “Human, Home sapiens’ is an original input, and I want it to be 
> searched by human, Human, homo sapiens or Homo Sapiens.
>
> Here is my workaround,
>
> public class TextDocValueField extends TextField {
>
>   @Override
>   public List<IndexableField> createFields(SchemaField field, Object value, 
> float boost) {
>     if (field.hasDocValues()) {
>       List<IndexableField> fields = new ArrayList<>();
>       fields.add(createField(field, value, boost));
>       final BytesRef bytes = new BytesRef(value.toString());
>       if (field.multiValued()) {
>         fields.add(new SortedSetDocValuesField(field.getName(), bytes));
>       } else {
>         fields.add(new SortedDocValuesField(field.getName(), bytes));
>       }
>       return fields;
>     } else {
> //      return Collections.singletonList(createField(field, value, boost));
>       return super.createFields(field, value, boost);
>     }
>   }
>
>   @Override
>   public void checkSchemaField(final SchemaField field) {
>     // do nothing
>   }
>
>   @Override
>   public boolean multiValuedFieldCache() {
>     return false;
>   }
> }
>
> I wish this can be supported by solr so that I don’t have to maintain my own 
> repo.
>
>
>
> What do you think?
>
> Regards,
> Harry
>
>
>> On Jan 5, 2016, at 10:51 PM, Alok Bhandari <alokomprakashbhand...@gmail.com> 
>> wrote:
>>
>> Thanks Markus.
>>
>>
>>
>> --
>> View this message in context: 
>> http://lucene.472066.n3.nabble.com/How-to-use-DocValues-with-TextField-tp4248647p4248797.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>

Reply via email to