[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