<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">There are two annotations clashing for same responsibilities:</div><div class="gmail_default" style="font-size:small">
- org.infinispan.query.Transformable</div><div class="gmail_default" style="font-size:small"> - org.hibernate.search.annotations.ProvidedId</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
as documented at the following link, these two different ways to apply "Id indexing options" in Infinispan Query, IMHO quite unclear when a user should use one vs. the other.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small"> - <a href="http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_requirements_for_the_key_transformable_and_providedid">http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_requirements_for_the_key_transformable_and_providedid</a></div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The benefit of @Transformable is that Infinispan provides one out of the box which will work for any user case: it will serialize the whole object representing the id, then hex-encode the buffer into a String: horribly inefficient but works on any serializable type.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">@ProvidedId originally marked the indexed entry in such a way that the indexing engine would consider the id "provided externally", i.e. given at runtime. It would also assume that its type would be static for a specific type - which is I think a reasonable expectation but doesn't really hold as an absolute truth in the case of Infinispan: nothing prevents me to store an indexed entry of type "Person" for index "personindex" with an Integer typed key in the cache, and also duplicate the same information under a say String typed key.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So there's an expectation mismatch: in ORM world the key type is strongly related to the value type, but when indexing Infinispan entries the reality is that we're indexing two independent "modules".</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I was hoping to drop @ProvidedId today as the original "marker" functionality is no longer needed: since we have</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">the option can be implicitly applied to all indexed entries, and the annotation is mostly redundant in Infinispan since we added this.</div><div class="gmail_default" style="font-size:small">
<br></div><div class="gmail_default" style="font-size:small">But actually it turns out it's a bit more complex as it servers a second function as well: it's the only way for users to be able to specify a FieldBridge for the ID.. so the functionality of this annotation is not consumed yet.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So my proposal is to get rid of both @Transformable and @ProvidedId. There needs to be a single way in Infinispan to define both the indexing options and transformation; ideally this should be left to the Search Engine and its provided collection of FieldBridge implementations.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since the id type and the value type in Infinispan are not necessarily strongly related (still the id is unique of course), I think this option doesn't even belong on the @Indexed value but should be specified on the key type.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Problem is that to define a class-level annotation to be used on the Infinispan keys doesn't really belong in the collection of annotations of Hibernate Search; I'm tempted to require that the key used for the type must be one of those for which an out-of-the-box FieldBridge is provided: the good thing is that now the set is extensible. In a second phase Infinispan could opt to create a custom annotation like @Transformable to register these options in a simplified way.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Even more, I've witnessed cases in which in Infinispan it makes sense to encode some more information in the key than what's strictly necessary to identify the key (like having attributes which are not included in the hashcode and equals definitions). It sounds like the user should be allowed to annotate the Key types, to allow such additional properties to contribute to the index definition.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Comments welcome, but I feel strongly that these two annotations need to be removed to make room for better solutions: we have an opportunity now as I'm rewriting the mapping engine.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sanne</div><div class="gmail_default" style="font-size:small"><br></div></div>