[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1131:
--------------------------------
Attachment: SOLR-1131-IndexMultipleFields.patch
This is a sketch to see how things look if we have SchemaField/FieldType return
Field[] rather then Field:
{code:java}
+ /**
+ * @deprecated use {...@link #createFields(String, float)}
+ */
public Field createField(String val, float boost) {
return type.createField(this,val,boost);
}
+
+ public Field[] createFields(String val, float boost) {
+ return type.createFields(this,val,boost);
+ }
{code}
I think this could work -- this would let FieldType#createFields() return a
list of fields. The issues i see are:
* indexing each field adds a for loop (maybe not a big deal?)
* FieldType#toInternal() may or may not relate to the actual indexed value
* FieldType#getAnalyzer() -- I guess the same analyzer would have to apply to
every field? I'm not sure what the implication is on this.
* what about #getRangeQuery()
> Allow a single field to index multiple fields
> ---------------------------------------------
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
> Issue Type: New Feature
> Components: Analysis
> Reporter: Ryan McKinley
> Attachments: SOLR-1131-IndexMultipleFields.patch
>
>
> In a few special cases, it makes sense for a single "field" (the concept) to
> be indexed as a set of Fields (lucene Field). Consider SOLR-773. The
> concept "point" may be best indexed in a variety of ways:
> * geohash (sincle lucene field)
> * lat field, lon field (two double fields)
> * cartesian tiers (a series of fields with tokens to say if it exists within
> that region)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
