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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
