Hi Thomas,Thanks for bearing with me here. I realize I'm raising use-cases that are not in the DdlUtils sweet spot perhaps; however, these cases are very important for the object-relational space I'm targeting.
On Feb 6, 2006, at 2:59 PM, Thomas Dudziak wrote:
On 2/6/06, Craig L Russell <[EMAIL PROTECTED]> wrote:Well, this describes my app and I guess I see it a bit differently. I'd like to use DdlUtils to capture any database schema recognizing that the full round trip development of schema is not supported.Really all I want here is accurate representation of the actual schema.It's still of great value to be able to point DdlUtils at a database and get its database-specific representation into a portable format and to be able to use this format to do such things as generation of POJO Java classes from the database. If we can't get the actual database representation, then it's of much less value for this application.Mhmm, I'm sorry but I think I still don't really understand what you're saying (just got back from the movies so I'm not fully here yet). Ain't database-specific representation and portability contradicting ?
Not really. If I want to use the Oracle database schema in a number of different use-cases, I want a library that gives me access to the specific column types. It's not portable across Oracle and Informix; it's portable across execution environments of my use-cases.
Of course, I could try to read the exact schema using Oracle's sql plus and encode that into an XML file. But what is the benefit ? I can only use this with an Oracle database (and likely only with certain versions) so it isn't portable. On the other hand, having a portable version (e.g. in terms of JDBC) looses detail that might or might not be important to the application. This is why DdlUtils currently focuses on database creation.
Ah, your sweet spot. And one of my use-cases is taking an object model defined with Java types and using DdlUtils to define the schema so it's portable across different databases.
If the developer has no problems defining the schema in terms of JDBC types and constraints, then there are no database specific details to loose.
Right, especially if the user can tell us how big their Strings are so we can map to the correct abstract database type. But I also want the user to be able to tell us about a specific Oracle type in case they know they want Oracle and don't care about database portability.
I can see the benefit of being able to read a schema from an existing database and to transfer that to another database. But for databases that contain database specifics, full detail preservation can IMO only be achieved if the databases are the same and a database-specific format is used (i.e. SQL something similar produced by a dump).
I agree that for this use-case, you would need a transformation from the Oracle types to the other database types, and do this transformation during a "copy schema" operation that would take the Oracle representation and apply some transformation rules to produce the other database format. I would see this transformer program as a utility not as a DdlUtils core feature.
When transfering to a different database product, you're bound to loose some detail. Of course, the shared feature set is likely larger than what JDBC provides. And there certainly is room for improvement in DdlUtils. E.g. it would be useful to have the ability to specify sequences in an database-independent way.
I see great value in this kind of behavior as well. Regards, Craig
regards, Tom
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
