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 <st...@hibernate.org> wrote: > > On Mon, May 1, 2017 at 4:26 AM Jan-Willem Gmelig Meyling < > jan-wil...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev