[
https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503978#comment-13503978
]
Michael Garski commented on SOLR-2592:
--------------------------------------
bq. I realized that we want something that clients (like cloud aware SolrJ) can
easily get to. So instead of config in solrconfig.xml that defines a parser for
the core, it seems like this should be a property of the collection?
Agreed - that makes perfect sense and was an oversight on my part. Persisting
that information in /collections/<collection_name> makes sense as it is a
collection level option.
One thing about my patch that has been on my mind has been the parsing of the
value to hash on from a delete by query on the client side. Currently it is
very simple and uses a regex to extract the value as using any of the query
parsers would require the cloud aware SolrJ client to also have the Lucene jar,
which I'm not sure is desired.
> Custom Hashing
> --------------
>
> Key: SOLR-2592
> URL: https://issues.apache.org/jira/browse/SOLR-2592
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Affects Versions: 4.0-ALPHA
> Reporter: Noble Paul
> Attachments: dbq_fix.patch, pluggable_sharding.patch,
> pluggable_sharding_V2.patch, SOLR-2592.patch, SOLR-2592_r1373086.patch,
> SOLR-2592_r1384367.patch, SOLR-2592_rev_2.patch,
> SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch
>
>
> If the data in a cloud can be partitioned on some criteria (say range, hash,
> attribute value etc) It will be easy to narrow down the search to a smaller
> subset of shards and in effect can achieve more efficient search.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
