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 22:43:23 GMT
Hi Thomas,

On Feb 6, 2006, at 2:25 PM, Thomas Dudziak wrote:

> On 2/6/06, Craig L Russell <Craig.Russell@sun.com> wrote:
>
>> I think that it would be more useful if DdlUtils distinguished
>> between the type actually stored in the database versus the mapping
>> from the abstract type to the actual type.
>>
>> Specifically, I'd like to see it be able to know the difference
>> between a column defined as LONG RAW and BLOB, since Oracle treats
>> them as different. If the user wants to define a real column type
>> they should be able to use either LONG RAW or BLOB. If the user just
>> wants an abstract column type LONGVARBINARY, then I have no problem
>> with DdlUtils creating a BLOB by default (if the user doesn't
>> override the generated column type with a specific type).
>>
>> I haven't looked closely enough into the implications of this, but I
>> have worked with column types on many projects and it is generally
>> useful to separate the actual column type from the generated column
>> type based on an abstract type.
>>
>> Another example is the abstract type String with a length. Databases
>> have different names for various lengths, e.g. VARCHAR, VARCHAR2,
>> CLOB. So the type for a String-6000 will be different for different
>> databases. But the actual column type should always be available to
>> the user of the API.
>
> Craig, I'm not exactly sure what you mean. If you're implying that the
> user should have (optional) control over the actual native type that
> is being used for a column, then I agree. This is something definitely
> planned, both for the API and the Ant tasks, though it is not targeted
> for the 1.0.

Yes, this is what I mean.
>
> However, it is the intention of DdlUtils to give users the ability to
> define the database model completely in terms of JDBC types and
> constraints, and then it just works.

Cool.

> Of course, this won't suffice for
> all applications, but it does not have to. Those apps that rely on
> specific features of a database (e.g. specific datatypes, stored
> procedures, triggers, ...) are bound to this database in any case, and
> so they would not want to use DdlUtils in the first place.

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.

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