[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789354#action_12789354
]
Chris A. Mattmann commented on SOLR-1131:
-----------------------------------------
bq. Maybe. It took me all of 30 seconds to figure out what it was doing. I'll
put some comments on it. While readability is important, Solr's goal is not to
make a product that a CS101 grad can read, it's too build a blazing fast search
server. That call could hit millions of times when indexing points.
Sure, maybe the goal isn't for a CS101 grad to be able to easily understand the
code, but SOLR's goal should include being open to ideas from the community
that involve reusing standard Java library functions and not rewriting based on
perception of speed and memory without empirical proof. Where's the evidence
that using things like split and trim are so much more costly than rewriting
those basic capabilities that they warrant not using them?
> 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.
