db-ddlutils-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <tom...@gmail.com>
Subject Re: oracle database model dangerously broken
Date Mon, 06 Feb 2006 22:25:42 GMT
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.

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. 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.

regards,
Tom

Mime
View raw message