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

[Sanne Grinovero]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140807/fb3a0b0b/attachment.html