db-ddlutils-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: oracle database model dangerously broken
Date Mon, 06 Feb 2006 23:44:37 GMT
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 <Craig.Russell@sun.com> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message