[hibernate-dev] Implement UserCollectionType for non-Collection types such as Guava's Multimap

[Emmanuel Bernard]

When you work in that area (mapping non Java Collection subclasses e.g. Guava Table), check out the work we have done in Bean Validation 2 around the subject of containers and extractors. You will likely be able to reuse these contracts as is. 
This does not address collections of collections. 

> On 1 May 2017, at 15:47, Steve Ebersole <steve at hibernate.org> wrote:
> 
> On Mon, May 1, 2017 at 4:26 AM Jan-Willem Gmelig Meyling <
> jan-willem at youngmediaexperts.nl> wrote:
> 
>> Hi Steve,
>> 
>> Thanks for your response to my questions! Good to see that my intuition
>> was right that this was currently not so trivial if even possible to do.
>> I’ll read up on the 6.0 code base as I am definitely willing to join the
>> ride for Hibernate 6. What is the current status of the Hibernate 6.0 type
>> redesign?
>> 
> 
> It is still very much fluid, but getting pretty close.  The "runtime model"
> is the piece you are interested in, and I have been working on that for the
> past few weeks.  Specifically you would be looking at CollectionPersister
> and friends.  You'd also be interested in CollectionType, but Type take on
> a slightly different role in 6.0 - the important bits move to
> CollectionPersister and the attribute definition.  CollectionPersister I
> have not spent a lot of time on yet.
> 
> The code for 6.0 is still just part of my fork, and i branch named
> `wip/6.0`: https://github.com/sebersole/hibernate-core/tree/wip/6.0
> 
> 
> 
>> What I was wondering though is whether the support of JDBC array types
>> would pave the way for array-based subselect fetching of to-many relations.
>> I am thinking of for example Postgresql’s array_agg function. In some of
>> our more complex domain entities I’ve been struggling with eagerly fetching
>> multiple to-many relations or deeper to-many relations without getting a
>> relatively large cross product. I currently do use subselect fetching for
>> this but I think having the ability to inline rows (perhaps even
>> recursively) in arrays would decrease query time, number of queries and
>> result set size significantly.
>> 
> 
> Possibly.  Hard to say yet.  First thing would be to analyze whether that
> approach actually is more performant and if so how much better the
> performance is (it has to justify the cost).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev