db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From César Obach-Renner <cob...@guru.com.ve>
Subject RE: Dynamic map creation on-the-fly
Date Sun, 25 Sep 2005 21:05:53 GMT
My comments in the text. (look for the <cesar> tags)
cesar

-----Mensaje original-----
De: Thomas Dudziak [mailto:tomdzk@gmail.com] 
Enviado el: Domingo, 25 de Septiembre de 2005 08:35 a.m.
Para: OJB Developers List
Asunto: Re: Dynamic map creation on-the-fly

On 9/25/05, César Obach-Renner <cobach@guru.com.ve> wrote:

> I've just searched with no success all arround the archive of this 
> list as well as the "user" one looking for what I haven't found yet on the
internet.
>
> I'm looging for an O/R mapping tool that encapsulates not only the 
> Relational aspect of the RDBMS underneath, but the maping itself as 
> well as the database "administration" (table creation, etc.) all of it at
runtime.
>
> For example, the following snippet would be enough without the need of 
> creating the maping for the "MyClass" object in the "repository_user.xml"
> file. The maping would be created on-the-fly dynamically as soon as 
> the broker receives an object of that class for the first time:
>
>         PersistenceBroker broker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
>         broker.beginTransaction();
>         broker.store(new MyClass(some-info));
>         broker.commitTransaction();
>
> It's obvious that the mapping should has to follow formal guidelines 
> like those worked by  Scott Ambler's white papers "Mapping Objects To 
> Relational Databases" and "The Design of a Robust Persistence Layer 
> for Relational Databases", so the auto-generated mapping ensures 
> robustness in the RDBMS schema for storing the objects.
>
> My idea writing to this list is to understand if this is implemented 
> today in OJB? If not, for when is it scheduled? And if it is aligned 
> with the project vision I would be very glad to work personally with 
> the project in order to make it happen.

OJB does not per se support this currently, though it would be easy to add
this with the help of DdlUtils. However you should be aware of the issues
surrounding such an approach, eg.

* what happens if there is already a table of that name there, perhaps with
a fitting structure, perhaps not ? should it be changed ot removed or what ?

<cesar> In general the dynamic mapping functionality may have two scenarios,
one simple that assumes there is no subset of the rdbms schema that maps to
the object and creates that subschema (let's call this scenario "blackbox"),
and other scenario which first tries to find that sub-schema and then maps
the object to it, and if it does not finds the subschema, creates it (let's
call this scenario "whitebox")

In the blackbox aproach the mapper just creates the table and identifies it
with the propietary metadata which attaches the new subschema with the
object (for future interactions optimization). If in that process finds a
table with the same name, it may include a prefix to the name of the table
that helps avoiding the collition.

The idea behind the functionality I'm looking for is to expose the rdbms as
an odbms which uses the Java class definitions as it's dataschema with a
fixed proyection inside the storage facility. This allouds the programmer to
focus only in the Java and OO environment without the hassle of managing
three different data definitions (the Java, the rdbms and the mapping) in
three differet protocols (java language, ddl and maping tool specs). Bottom
line, Java definition classes are the only schema information available
(without metadata like those in Xdoclet or EJB3 annotations). I like very
much this approach because even though I have it from odbms like db4o, there
are implementations where the operator of the system only trust in
commercial rdbms like Oracle, DB2, etc.

Even though the only scenario that makes sense is the blackbox, for
completeness I can tell that in the whitebox approach the dynamic mapping
functionality looks for an entity "similar" to the object that has to be
mapped, the mapper will have to receive a "confirmation" (from the
programmer) that the entity is really that object unless the entities in the
database have some kind of sematized description compatible with the one
used by this tool that confirms that both the object and the entity are the
same thing. This scenario is obvio

</cesar>

* what if the class name is too long (eg. for some databases the identifier
length must not exceed 18 characters) or there is more than one class with
the same unqualified (short) name ?

<cesar>
The most simple way of resolving this is to use non-mnemonic ids for the
table names and maintain a mapping table which ties this ids with the java
class fully qualified name; for example, the id may be derivated from the
fully qualified name of the class with some algorithm that avois the lookup
of the table id in the mapping table. Even though this approach is very ugly
in terms of browsing the data from the rdbms perspective, it resolves the
problem. 

Now, this is no the only way, I can list a number of different options that
may be tried for each class before using the previusly explained method,
which may identify the tables with ids mnemonic to the java class name.

</cesar>

* it is perhaps not always possible to see at the SqlException that a sql
operation has failed because the table is not yet there - this largely
depends upon the quality of the jdbc driver implementation

<cesar>
This is something that may have it's workarround even creating a jdbc driver
compatibility tolkit which may "certificate" jdbc drivers compliance with
this kind of behaviors.
</cesar>

regards,
Tom

<cesar>

I'm aware of this kind of issues since I developed once a tool like this
back in 1998 after I participated in some discussions with the Toplink
developement team in San Jose.

Which would be the process to evaluate the incorporation of this optional
functionality and my collaboration to the project for this?

Cheers
cesar
</cesar>

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For additional
commands, e-mail: ojb-dev-help@db.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message