Re: [hibernate-dev] Hibernate as a persistence engine
First, this code does not build on the JPA 2 metamodel. It was started
actually before JPA 2 was started. It does however share some similar
concepts with the JPA 2 metamodel which I suggested we should leverage.
Of course the JPA 2 metamodel makes the assumption that the object model
is what we would call EntityMode.POJO which would have to be accounted
for.
Two very important points to keep in mind here:
1) There need be a separation between the "database model" and the
"entity model" and there should be a "binding" that describes the
relation between the 2. As far as Hibernate processing is concerned
(run-time) it is this binding information that is of the utmost
importance. Yes you are correct that it most understand how to inject
and extract attribute values, etc but really this is largely ancillary;
in most cases the Hibernate internals deal with the "raw tuples" (the
values array).
2) The order in which the various models get built is important. The
database model and the entity model must exist before we build the
binding. There are mainly 2 reasons for this:
a) ideally the binding would reference the corresponding database model
object AND entity model object for navigation purposes.
b) type/mapping/naming inference.
On Wed, 2009-12-23 at 21:54 +0100, Adam Warski wrote:
Hello,
I took a look at the new meta-model proposed by Steve; in case anybody hasn't seen it
it's here:
http://anonsvn.jboss.org/repos/hibernate/sandbox/trunk/new-metadata/
If I correctly understood Steve and the code, the model builds on the JPA2 meta-model. In
the proposition there are three levels of meta-data:
1) database
2) mapping
3) java
However as Steve mentioned on IRC, there is a problem with alternate entity modes (today
these are "map" and "xml").
(For me they are very useful, as Envers uses the "map" entity mode to
dynamically generate the audit entities.)
Don't you think that an "entity" meta-data level would be useful?
The basic layers would then be:
1) database - information about tables, columns, foreign keys, indexes
2) mapping - binding between levels 1 and 3, that is, assignment from properties to
columns, from entities to tables etc
3) entity - information about entity names, property names, property types (a property
can be a simple value, many-to-one, one-to-many, (...) relation, a component etc). For
example, a many-to-many relation property would have no idea that it's mapped using a
join table.
Now there could be several layers that build on that. Each such layer would have to
specify what is an entity and what is a property; how to get/set a property from an
entity; how to read other meta-data (from annotations? or from xml?)
4a) java - an entity is a class; holds information if properties are accessed using
fields or getters/setters
4b) map - an entity is a map; properties accessed using Map.get()
4c) xml
In the longer run, maybe Hibernate could become more of a "persistence
engine".
That is, it would provide a nice entity abstraction of a database (so abstracting level 1
using level 3 as the access point).
It would play nicely with another project that I have in mind, namely an ORM for Scala
that would use Hibernate. Only a new entity mode (level 4) would have to be written, which
would be a translation from Scala constructs to entities, properties, relations. (Maybe
that would even be something that Bob could use in TorqueBox.)
What do you think?
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org