[
https://issues.apache.org/jira/browse/SOLR-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2671:
---------------------------
Attachment: SOLR-2671.patch
{quote}
Not really: currently the xml files have two properties, but the Solr APIs
expose indexOptions(), which it then sets on the lucene Field when it makes it.
Alternatively, the Solr APIs could have two booleans, or a real class or
something like that so that nobody ever "sees" indexOptions unless they
interact with a lucene Field.
{quote}
Good point ... i think getting IndexOptions out of SchemaField and down into
FieldType (where the only way you see it is if you are directly dealing with a
lucene Field Object) makes sense.
Take a look at the attached patch -- it replaces SchemaField.indexOptions()
with two boolean methods corresponding to the properties (and adds back a
deprecated omitTf() as an alias - that was removed in LUCENE-2048 but isn't
back-compat on the 3x branch) and moves the IndexOptions logic into
FieldType.getIndexOptions (which is consistent with the getFieldStore and
getFieldIndex that were already in that class)
Opinions?
(obviously we can always add better javadocs, but i wanted to start with the
important part)
> SchemaField.indexOptions() should return null if SchemaField.indexed()
> returns false
> ------------------------------------------------------------------------------------
>
> Key: SOLR-2671
> URL: https://issues.apache.org/jira/browse/SOLR-2671
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2671.patch
>
>
> It doesn't make sense for SchemaField.indexOptions() to return any of the
> values from the IndexOptions enum if the field is not going to be indexed at
> all.
> we should return null to prevent missleading any code that calls that method
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
