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(a)hibernate.org>
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
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
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