Hi Thomas, On Feb 6, 2006, at 2:25 PM, Thomas Dudziak wrote:
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.
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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
