I just read it. Some random remarks.
Small correction on the description of the legacy Type also offers a navigation on the
cardinality and knowledge of the Hibernate structures like assocaitions (one to one etc),
component, any etc and mutability. But that’s minor and all covered by your proposal.
BasicType does not handle multiple column and compositeType is the mebedded case. How
would multi-column types would be handled?
Positional types only, not named columns: that is likely going to impact OGM and it needs
to play well with that new approach. Guillaume or Davide, if you ahve 30 mins to spare,
that might be interesting to check how the GridType could cope with positional parameters
and not named columns for “nullSafeSet / Get calls"
Why do you need to ”unscope" the TypeConfiguration? What do you gain from it? I’m
trying to picture a reuse use case?
Methods of Type needing Session: I used to call them passing null in some old code and
hoping for the best. Are the reasons for using Session still present? Would be nice to get
rid of that.
On the genericization of Type, it would be extremely nice indeed for OGM, but it would
require to genericize SqlTypeDescriptor and its methods essentially. Not necessarily super
trivial.
On 22 Jun 2016, at 18:54, Steve Ebersole <steve(a)hibernate.org>
wrote:
I started a wiki discussing the proposal for the type system redesign.
Let's get discussions about it starter sooner rather than later. Thanks!
https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev