[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786944#action_12786944
]
Grant Ingersoll edited comment on SOLR-1131 at 12/9/09 1:33 PM:
----------------------------------------------------------------
OK, here's my take on this. I took Yonik's and merged it w/ a patch I had in
the works. It's not done, but all tests pass, including the new on I added
(PolyFieldTest). Yonik's move to put getFieldQuery in FieldType was just the
key to answering the question of how to generate queries given a FieldType.
Notes:
1. I changed the Geo examples to be CoordinateFieldType (representing an
abstract coordinate system) and then PointFieldType which represents a point in
an n-dimensional space (default 2D). I think from this, we could easily add
things like PolygonFieldType, etc. which would allow us to create more
sophisticated shapes and do things like intersections, etc. For instance,
imagine saying: Does this point lie within this shape? I think that might be
able to be expressed as a RangeQuery
2. I'm not sure I care for the name of the new abstract FieldType that is a
base class of CoordinateFieldType called DelegatingFieldType
3. I'm not sure yet on the properties of the generated fields just yet. Right
now, I'm delegating the handling to the sub FieldType except I'm overriding to
turn off storage, which I think is pretty cool (could even work as a copy field
like functionality)
4. I'm not thrilled about creating a SchemaField every time in the createFields
protected helper method, but SchemaField is final and doesn't have a setName
method (which makes sense)
Questions for Yonik on his patch:
1. Why is TextField overriding getFieldQuery when it isn't called, except
possibly via the FieldQParserPlugin?
2. I'm not sure I understand the getDistance, getBoundingBox methods on the
GeoFieldType. It seems like that precludes one from picking a specific
distance (for instance, some times you may want a faster approx. and others a
slower more accurate calculation)
Needs:
1. Write up changes.txt
2. More tests, including performance testing
3. Patch doesn't support dynamic fields yet, but it should
was (Author: gsingers):
OK, here's my take on this. I took Yonik's and merged it w/ a patch I had
in the works. It's not done, but all tests pass, including the new on I added
(PolyFieldTest). Yonik's move to put getFieldQuery in FieldType was just the
key to answering the question of how to generate queries given a FieldType.
Notes:
1. I changed the Geo examples to be CoordinateFieldType (representing an
abstract coordinate system) and then PointFieldType which represents a point in
an n-dimensional space (default 2D). I think from this, we could easily add
things like PolygonFieldType, etc. which would allow us to create more
sophisticated shapes and do things like intersections, etc. For instance,
imagine saying: Does this point lie within this shape? I think that might be
able to be expressed as a RangeQuery
2. I'm not sure I care for the name of the new abstract FieldType that is a
base class of CoordinateFieldType called DelegatingFieldType
3. I'm not sure yet on the properties of the generated fields just yet. Right
now, I'm delegating the handling to the sub FieldType except I'm overriding to
turn off storage, which I think is pretty cool (could even work as a copy field
like functionality)
4. I'm not thrilled about creating a SchemaField every time in the createFields
protected helper method, but SchemaField is final and doesn't have a setName
method (which makes sense)
Questions for Yonik on his patch:
1. Why is TextField overriding getFieldQuery when it isn't called, except
possibly via the FieldQParserPlugin?
2. I'm not sure I understand the getDistance, getBoundingBox methods on the
GeoFieldType. It seems like that precludes one from picking a specific
distance (for instance, some times you may want a faster approx. and others a
slower)
Needs:
1. Write up changes.txt
2. More tests, including performance testing
3. Patch doesn't support dynamic fields yet, but it should
> Allow a single field type to index multiple fields
> --------------------------------------------------
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
> Reporter: Ryan McKinley
> Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: SOLR-1131-IndexMultipleFields.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.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.
