[hibernate-dev] 6.0 proposal - CollectionTuplizer
Steve Ebersole
steve at hibernate.org
Thu May 18 11:23:30 EDT 2017
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?
More information about the hibernate-dev
mailing list