Hi Daniel, On Feb 20, 2008 1:04 AM, Daniel López <[EMAIL PROTECTED]> wrote:
> In SQL, you can have something like... > ... > CREATE TABLE TFOR_CATEGORY > ( > CAT_CODE CHAR(32) NOT NULL, > ... > CONSTRAINT KFOR_CAT_PK PRIMARY KEY (CAT_CODE) > ) > ... > and in our case, we generated some extra XML like... > ... > <table name="TFOR_CATEGORY"> > <primarykey name="KFOR_CAT_PK"> > <column col="1" name="CAT_CODE"/> > </primarykey> > <column name="CAT_CODE" primaryKey="true" required="true" > size="32" type="CHAR"/> > ... > This way we don't lose the KFOR_CAT_PK name and we can use it, for > example, to generate some error handling code that detects easily if the > primary key constraint was violated. On the other hand that also means > that rebuilding the DB from the XML schema does not lose that > information, and we need those names to follow our naming conventions. Ah, yes, this is covered by http://issues.apache.org/jira/browse/DDLUTILS-83. Main reason why this is not yet implemented is that it is not supported by the current DTD, and instead depends on the XML Schema (http://issues.apache.org/jira/browse/DDLUTILS-117). > We found out that the numerical columns had also an attribute for the > RADIX, usually radix is always 10 but it could be different if the colum > stores directly hexadecimal numbers (radix 16)... Unless for some > special cases, not taking into account the radix would not be a problem. > We haven't come across any column like that but just in case, we added > it ;). Mhmm, interesting, do you know which databases support radix ? > Nothing fancy, just to take into account that a java.util.Date is better > stored as TIMESTAMP, only available in versions > Oracle 8.1.7, as DATE > would mean losing the milliseconds. I just saw a note in Torque on how > to handle that: > http://db.apache.org/torque/version-specific/database-howtos/oracle-howto.html > SO I guess that it is covered. We were using a previous version of > Torque were this was not being handled, so we had done it ourselves.. Yeah, just explicitly specify the platform to be oracle9 or oracle10 and DdlUtils will use TIMESTAMP instead of DATE. > I got the source from SVN and I'll see if I can patch at least the > regexp tablename detector to help with issue DDLUTILS-87. If you could attach a unified diff to the JIRA issue, that would be awesome! cheers, Tom
