[hibernate-dev] 6.0 - Type redesign

[Steve Ebersole]

I am working on a larger response to some current challenges, but here is a
quick response to your specific points...

On Wed, Jul 20, 2016 at 12:50 PM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> BasicType does not handle multiple column and compositeType is the
> mebedded case. How would multi-column types would be handled?
>

In terms of what exactly?  Assuming you mean access to the JDBC
descriptors, that is still being determined.  At the moment there is no
single Type-level access to this information.  Each specific Type
sub-interface defines access differently.  I am not a fan of that that
aspect.  The other approach is to define a plural form on Type
(Type#getColumnMappings), and BasicType would just ensure that there is
just one.


Why do you need to ”unscope" the TypeConfiguration? What do you gain from
> it? I’m trying to picture a reuse use case?
>

Functionally we do not gain anything.  I was just trying to be balanced.
We injected the SF into the TypeConfiguration, I wanted to un-inject it as
well for 2 reasons:

   1. release the reference to the SF
   2. prepare the TypeConfiguration for binding to another SF.

The only use case I had in mind was tests where we occasionally build
multiple SF instances from a single Metadata.


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.
>

This is only ever needed (sometimes) from EntityType.  I guess it depends
which specific method(s) you are asking about.  For some (reading, writing)
yes I think we will continue to need the Session: it is used for access to
JDBC as well as other needed interactions with the Session/PC (scheduling
ids for batch load, etc).  For other methods, maybe not.


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.
>

I understand that.  It is not a primary goal for me tbh.  But if we can get
a decent design for the ORM case and can see an easy way to extend this to
OGM without negatively impacting ORM I am all for it.  Given the delegation
to Binder and Extractor I think this will be doable, although I assume we
will need some parameterized param object to make this work.  The paam
object would give us access to "JDBC services" in ORM and something else in
OGM.