[hibernate-dev] Processing mapping information followup

[Max Rydahl Andersen]

> What I am discussing here has no effect on this concern.
> 
> 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.

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.

> 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 ;)

> However, keep in mind that this is a completely new piece of code.  I would be shocked if we get it completely right out of the gate.  So just let us know where we missed stuff.

will try - hardest part is to figure out where to look to know what API to actually use to try it at this point, secondly finding the time ;(

/max

> 
> 
> On 06/14/2011 05:40 AM, Max Rydahl Andersen wrote:
>> Any idea how much this would affect tools ability to reflect on the metamodel without requiring the actual
>> model classes and types to be available ?
>> 
>> At what time will the classes/types be *required* to be available?
>> 
>> i.e. for H3 as long as we filled out all the type info in the xml hibernate did not require
>> access to types or model classes until buildMappings() occurred.
>> 
>> Allowing us to iterate the mapped classes and tables for code generation.
>> 
>> /max
>> 
>> On Jun 13, 2011, at 23:29, Steve Ebersole wrote:
>> 
>>> Wanted to start a follow up discussion to the conversation we had at the
>>> IRC meeting on 6/13 with regards to changing the way we process mapping
>>> information to follow dependencies in the various types of information.
>>> 
>>> What we do currently (in the metamodel code) is essentially the same as
>>> the legacy code.  That is to say we process through a mapping source in
>>> full and then move on to the next one, saving off "second passes"
>>> whenever we encounter information on which we have to wait.  The second
>>> passes in the new metamodel code are isolated I guess (so far) to
>>> org.hibernate.metamodel.source.internal.EntityReferenceResolver
>>> 
>>> What I proposed instead is quite different, more like what I did for the
>>> rest of the MetadataImpl constructor code in terms of defining
>>> dependencies and processing stuff in an order that makes sure to avoid
>>> the need for second passes.
>>> 
>>> Here is the initial swab at the levels of information:
>>> 1) entity - basic entity information such as name, hierarchy
>>> 2) identifiers - normal identifiers could almost be handled in the first
>>> level.  key-many-to-one still needs some form of delayed queuing.
>>> 3) secondary tables
>>> 4) attributes
>>> 5) associations
>>> 
>>> The dependencies flow downward; (2) depends on (1); (3) depends on (2); etc.
>>> 
>>> I liked handling (3) secondary tables separately because they basically
>>> expand the possible set of columns available for (4) and (5).
>>> 
>>> --
>>> Steve Ebersole<steve at hibernate.org>
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> /max
>> http://about.me/maxandersen
>> 
>> 
>> 
> 
> -- 
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org

/max
http://about.me/maxandersen