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