[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1131:
-------------------------------
Attachment: diff.patch
SOLR-1131.patch
Here's an updated patch that fixes a lot of little bugs - hopefully others can
use this as a base so we don't lose all the little changes. I also attached a
diff of the patch to the previous patch to help people see what's changed
(yuck... doesn't seem that readable though). This isn't finished though - I
only got to the FieldType / IndexSchema changes, and *some* of the ValueSource
stuff. I didn't get to distance and value source parsing stuff.
Some of the changes:
- small javadoc cleanups
- fix subFieldSuffix so that it actually uses that suffix
- make any utility methods on FieldType/IndexSchema dealing with "poly" field
creation package protected - I don't think we want these public... it's
specific for a field that adds only to other fields that it defines (with a
specific naming convention) all of the same type. They probably don't even
belong on the base classes, but I don't care so much if they aren't public or
protected, we can remove later.
- make PointType actually delegate to the subFieldType... before it was
assuming thinks like TermQuery and TermRangeQuery... this would have actually
disabled NumericRangeQuery speedups!
- remove SchemaField creation from PointType - we should get fields from the
schema
- fixed some value sources that didn't weight correctly
- fix createFields() to return Fieldable instead of Field
When I fixed up point type, I did so in many places by assuming 2 points (so it
will break for other dimensions).
I had been working off the assumption that we wanted a geo specific base class
to delegate some things to (like the most efficient way to get a bounding box,
etc). If so, we need to decide what that class will be. Making it point or
coordinate already bakes in a lot if implementation details (subType stuff).
Do we want geo to just work off of a generic n dimentional point class, or
should we have a 2d lat/lon? It does feel like we're loosing something by
trying to over-generalize. The PointTypeValueSource is inner-loop stuff, so I
did specialize that for lat/lon.
> 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: diff.patch, SOLR-1131-IndexMultipleFields.patch,
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.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.
