There are two annotations clashing for same responsibilities: - org.infinispan.query.Transformable - org.hibernate.search.annotations.ProvidedId
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. - http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_requirements_for_the_key_transformable_and_providedid 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. @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. 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". I was hoping to drop @ProvidedId today as the original "marker" functionality is no longer needed: since we have org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit() the option can be implicitly applied to all indexed entries, and the annotation is mostly redundant in Infinispan since we added this. 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. 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. 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. 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. 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. 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. Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
