Re: [hibernate-dev] Processing mapping information followup
>> In the new terminology, what we are discussing is the process
for handling "metadata sources" (o.h.metamodel.source). What you describe is
really a parallel source (o.h.metamodel.source.jdbc???). So it is going to be completely
up to the developer of that code how the binding of source information to metamodel
works.
>
> jdbc sources is just for reverse engineering.
>
> If you are using the xml as your source that is the source for code generation that
needs to be lazy.
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 ?
Those are also code generated, or at least is for H3.
As I recall Components were modelled by the same mechanism that UserTypes uses.
>> We will strive to make sure nothing requires the domain
classes to be present. However, please not that in developing this new code I made a
distinction. Specifically, I believe this principal does *not* extend to types,
identifier generators, etc. Entity classes, component classes.. anything that is actually
part of the domain model though we will strive to make not required to build this
metadmodel. You specifically asked about "model classes and types"; just wanted
to highlight the difference in my mind.
>
> Yes, understood - custom types are required, just the call to .getReturnedClass()
that should be avoided if .getReturnedClassName() or .getReturnedEntityName() can suffice
;)
Again, I disagree with this use case. Even going back and thinking through the case of
enums. Right now I totally see no benefit to making types non-resolvable in any
form/fashion with regards to their typing information (jdbc and java). So I plan on
having type resolution to both JDBC type code(s) and java type (Class) be available.
Ok - I guess we'll just have to wait and see.
> i.e. a related "dream" of mine is that the metamodel is
so decoupled that independent of the source of the mappings I can inject my own
understanding
> of entities - and provide the reflection without actually having classes, i.e. base
it on the model eclipse JDT has about classes and make it possible to work
> with non-compilable classes to be able to use hibernate core to validate the overall
mappings.
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.
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.
Unfortunately I don't have time to attempt to migrate hibernate tools usecases. We are
trying to do that now but awaiting actual code that we can try it against.
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.
/max
http://about.me/maxandersen