My comments in the text. (look for the <cesar> tags) cesar -----Mensaje original----- De: Thomas Dudziak [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
