On 2/6/06, Craig L Russell <[EMAIL PROTECTED]> 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
