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 <emman...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
