As part of removing most Type sub-types we are left with the question of how to handle the role served by CollectionType. Andrea and I came up with a proposal that not only serves that purpose but also allows a level of customization we have so far not supported but which has been asked for a few times (mostly as part of framework/language integration into Hibernate; Ceylon, etc). Here is the proposal: /** * Encapsulates collection type specific behavior/information * <p/> * NOTE : the name "tuplizer" was chosen as this really serves * same logical purpose as the entity and component tuplizers * do entities and components respectively. */ interface CollectionTuplizer<C> { /** * Access to the type of the collection. This * is expected to be an interface. Used to create * a registry against which we can resolve the * reflected attribute type. E.g. an attribute * defined as `List` would be resolved to the * CollectionTuplizer that deals with lists */ Class<C> getCollectionJavaType(); /** * Create an empty instance of the collection wrapper */ PersistentCollection<C> create(int anticipatedSize); /** * Wrap an existing "raw" view of the collection */ PersistentCollection<C> wrap(Object rawCollection); /** * Creates the representation of this plural attribute * according to the runtime domain model view. */ <O> PluralPersistentAttribute<O,C,?> generatePluralAttribute(); // anytihng else? element comparator, etc? } Thoughts? Suggestions?

Would this allow for queries of multiple keys, like this? SELECT * FROM tbl WHERE (key1, key2) IN ( (val1k1,val1k2), (val2k1,val2k2)... ) I started working on trying to fit something like this in 5.2 and see what problems I would encounter, but haven't had time to finish it. On 16 June 2017 at 17:14, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > No feedback, so I will work in this direction then... > > On Thu, May 18, 2017 at 10:23 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> As part of removing most Type sub-types we are left with the question of >> how to handle the role served by CollectionType. Andrea and I came up with >> a proposal that not only serves that purpose but also allows a level of >> customization we have so far not supported but which has been asked for a >> few times (mostly as part of framework/language integration into Hibernate; >> Ceylon, etc). >> >> Here is the proposal: >> >> /** >> * Encapsulates collection type specific behavior/information >> * <p/> >> * NOTE : the name "tuplizer" was chosen as this really serves >> * same logical purpose as the entity and component tuplizers >> * do entities and components respectively. >> */ >> interface CollectionTuplizer<C> { >> /** >> * Access to the type of the collection. This >> * is expected to be an interface. Used to create >> * a registry against which we can resolve the >> * reflected attribute type. E.g. an attribute >> * defined as `List` would be resolved to the >> * CollectionTuplizer that deals with lists >> */ >> Class<C> getCollectionJavaType(); >> >> /** >> * Create an empty instance of the collection wrapper >> */ >> PersistentCollection<C> create(int anticipatedSize); >> >> /** >> * Wrap an existing "raw" view of the collection >> */ >> PersistentCollection<C> wrap(Object rawCollection); >> >> /** >> * Creates the representation of this plural attribute >> * according to the runtime domain model view. >> */ >> <O> PluralPersistentAttribute<O,C,?> generatePluralAttribute(); >> >> // anytihng else? element comparator, etc? >> } >> >> Thoughts? Suggestions? >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev