There is an additional complex choice to make. Considering that Infinispan has this separate notion of Key vs Value, and both have to contribute to building the final indexed Document, why is it that we allow the decision of which index is being targeted to be made by *the type of the value*? I think the index definition belongs as a responsibility to the *type of the identifier*, the value should at most help to identify a shard among the ones identified by its key. !!! -> We might want to consider imposing a hard limitation of not allowing a single index to be shared across multiple key types. This implies the @Indexed annotation and its other key options should be defined on the keys, not the values. If we did that, it wouldn't matter if the index is defined on the key or on the value as there would be a 1:1 possible combination. Does anyone see this as a strong limitation or usability concern? This would also resolve a couple of performance problems. Beyond this, considering it's valid (and sometimes useful) to store PersonFile p = ... cache.put( p.taxcode, p ); cache.put( p.uniquename, p ); As a user I think I might even want to define an alternative index mapping for PersonFile, depending on if it's being stored by uniquename or by taxcode. That's totally doable with the Search engine, but how do you envision the user to define this mapping? He can't use annotations on PersonFile, so the user needs to be able to register some form of programmatic mapping linked to the different key types. There is an additional flaw, which is that I'm implying that taxcode and uniquname are of a different type: otherwise we couldn't distinguish the two different meanings of the two put operations. This is generally a fair assumption as you wouldn't want to have key collisions if you're storing in such a fashion, but there might be a known business rule for which such a collision is impossible (i.e. the two codes having a different format). So while you probably shouldn't do this in a strong domain, it's a legal usage of the Cache API. Considering these pitfalls I think I have successfully convinced myself that we should not allow for a different mapping for the same type of key. Question remains if it's more correct to bind the index identification (the name) to the key type. @Hardy yes I will need the Infinispan team's thoughts too, but don't feel excluded, there aren't many smart engineers around knowing about the Infinispan/Query usage :) Cheers, Sanne On 7 August 2014 22:50, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: