No feedback, so I will work in this direction then...
On Thu, May 18, 2017 at 10:23 AM Steve Ebersole <st...@hibernate.org> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
