[ 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.