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