[ https://issues.redhat.com/browse/ISPN-12170?page=com.atlassian.jira.plugi... ] Yoann Rodière updated ISPN-12170: --------------------------------- Description: We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID then use it as a routing key.   A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index.   With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs.   This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP.   See the implementation of RoutingKeyBridge in Infinispan, and see [https://hibernate.atlassian.net/browse/HSEARCH-3891] was: We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID and use it as a routing key.   A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index.   With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs.   This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP.   See the implementation of RoutingKeyBridge in Infinispan, and see https://hibernate.atlassian.net/browse/HSEARCH-3891 -- This message was sent by Atlassian Jira (v7.13.8#713008)