[hibernate-dev] [Search] @Transformable vs @ProvidedId

[Emmanuel Bernard]

I basically tl;dr; the whole thread for the obvious reason that it is
too long :)
But skimming through it made me think of the following.
Would it make sense to index Map.Entry<Key,Value> with @IndexedEmbedded
or @FieldBridge on Map.Entry.getKey() / Map.Entry.getValue()?
At a conceptual level at least.

One more reasons to get free form entities.

On Thu 2014-08-07 18:56, Sanne Grinovero wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev