[hibernate-dev] Processing mapping information followup

[Steve Ebersole]

>> Again non resolution of the domain classes is already handled.  Or should be.  That has been a consistent mantra as we have developed this new metamodel code.  As for types...
>
> Okey - is Components covered by this ?

Components are domain classes, so yes they would fall under what we 
discussed with entities.  Yes the enums are domain classes as well, but 
its a very special case because of the use of an explicit Type 
definition in the mapping.


>> org.hibernate.metamodel.Metadata is an interface.  You are free to build that in any way you see fit.  Today, the stuff contained within Metadata is not, though I am certainly open to such a discussion if you think it makes sense for your use cases.
>
> The usecase I was thinking of is so I can delegate the class metadata and construction of instances. I actually think H3 had most of this, except it wasn't easy to override the defaults globally and thus you
> had to thoroughly massage the model to make it happen - leaving behind the biggest issue, that classloading of entities/types were not bound by a sessionfactory so you ended up having class cast problems when running in Eclipse/osgi.

Well we all pretty much agree there were issues with the old model. 
That is why we are redoing it.


>> This is THE reason I wanted your input and eyes on this design.  The earlier we address this stuff the better it would have been.
>
> As far as I know I already given this feedback multiple times.

Well we elicited your input on our discussions.  But until one "gets 
dirty" with the code, its hard to tell where things will lead and how 
ideas evolve in implementation.  Again, we tried to keep in mind your 
input.  But the best means of validating that is test cases which we 
simply do not have and did not have.


> Any git branches/forks where Configuration is removed or a test is present that doesn't use the "old " Configuration approach and i'll try and take a new look.

There are some tests in master

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org