[
https://issues.apache.org/jira/browse/SOLR-7247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367070#comment-14367070
]
Paolo Cappuccini edited comment on SOLR-7247 at 3/18/15 1:03 PM:
-----------------------------------------------------------------
I can share my personal workaround.
I use deleteByquery to delete the document (because it's automatically routed
to proper shards)
I specify "shards" parameter for realtimeget , so the realtimeget don't use
hashing logic to route but instead use "shards" specified.
>From user perspective both are very ugly ways to route documents but I think
>that both behaviors could be the easier solution to be implemented internally
>just in case of routeField and make things transparent to user.
I think that the loss of performance is the price to pay if one want use custom
routeField.
Anyway the documentation should underline this loss of performance but the
user can still specify "_route_" parameter if his application have some
business rule chaining "id" and "routeField" so RealTimeGet can still use
"_route_" to calculate properly the shard (if the realtimeget component would
care of this parameter insteand of "shards")
Actually realtimeget just use "getTargetSlice" . In case of "_route_" it should
use getSearchSlices
was (Author: cappuccini):
I can share my personal workaround.
I use deleteByquery to delete the document (because it's automatically routed
to proper shards)
I specify "shards" parameter for realtime get , so the realtimeget don't use
hashing logic to route but instead use "shards" specified.
>From user perspective both are very ugly wayes to route docuemts but I think
>that both behaviours could be the easier solution to be implemented internally
>just in case of routeField and make things transparent to user.
I think that the loss of performance is the price to pay if one want use custom
routeField.
Anyway and documentation should underline this, the user can still specify
"_route_" parameter if his application have some business rule chaining "id"
and "routeField" so RealTimeGet can still use "_route_" to calculate properly
the shard.
> sliceHash for compositeIdRouter is not coherent with routing
> ------------------------------------------------------------
>
> Key: SOLR-7247
> URL: https://issues.apache.org/jira/browse/SOLR-7247
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.10.3
> Reporter: Paolo Cappuccini
> Assignee: Noble Paul
>
> in CompositeIdRouter the function sliceHash check routeField configured for
> collection.
> This make me to guess that intended behaviour is manage alternative field to
> id field to hash documents.
> But the signature of this method is very general ( can take id, doc or
> params) and it is used in different ways from different functionality.
> In my opinion it should have overloads instead of a weak internal logic. One
> overload with "doc" and "collection" and another one with "id" , "params" and
> "collections".
> In any case , if "\_route_" is not available by "params" , "collection"
> should be mandatory and in case of RouteField, also "doc" should be mandatory.
> This will break SplitIndex but it will save coherence of data.
> If i configure routeField i noticed that is broken the DeleteCommand (this
> pass to sliceHash only "id" and "params" ) and SolrIndexSplitter ( this pass
> only "id" )
> It should be forbidden to specify RouteField to compositeIdRouter or
> implements related functionality to make possible to hash documents based on
> RouteField.
> in case of DeleteCommand command the workaround is to specify "_route_" param
> in request but in case of Index Splitting is not possible any workaround.
> In this case it should be passed entire document during splitting ("doc"
> parameter") or build params with proper "\_route_" parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
