[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789240#action_12789240
]
Grant Ingersoll commented on SOLR-1131:
---------------------------------------
{quote}
Quick comment based on a spot check of the changes to IndexSchema: rather than
make polyField special somehow w.r.t IndexSchema, and add a
FieldType.getPolyFieldNames, etc, I had been thinking more along the lines of
having an IndexSchema.registerDynamicFieldDefinition - just like the existing
registerDynamicCopyField. This would (optionally) allow any field type to add
other definitions to the IndexSchema. I continue to think it would be good to
stay away of special logic for "polyfields" in the IndexSchema.
{quote}
So, then the FieldType would register it's Dynamic Fields in it's own init()
method by calling this method? That can work.
bq. Why use Dynamic Field array
The array is sorted and array access is much faster and we often have to loop
over it to look it up.
{quote}
CoordinateFieldType: why process > 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
{quote}
OK. Actually, this should just be in the derived class, as it may be the case
some other CoordinateFieldType has multiple sub types.
{quote}
# parsePoint in DistanceUtils, why use ',' as the separator - use ' ' (at least
conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
# parsePoint - instead of complicated isolation loops, why not just use trim()?
I've taken that approach in the patch I've attached.
{quote}
I think comma makes sense. As for the optimization stuff, I agree w/ Yonik,
this is code that will be called a lot.
* when checking for isDuplicateDynField, if it is, nothing is done.
Shouldn't this be where an exception is thrown or a message is logged? In the
patch I'm attaching I took the log approach.
{quote}
It is logged, but for the poly fields, if the dyn field is already defined,
that's just fine.
> 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.Mattmann.121009.patch.txt, 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.
