db-ddlutils-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel López <D.Lo...@uib.es>
Subject Re: Additions to generated XML
Date Wed, 20 Feb 2008 09:04:32 GMT
Hi Thomas,

Glad to hear you are so open to colaboration, let me see if I can show 
you what I meant with some examples.

>> .- Include the name and information of the constraints, so it is not
>> lost. We usually put explicit names in our constraints and those names
>> can be used to identify errors more easily, so we need them in the XML
>> so we can generate exception handling code from there. Moreover, we
>> don't want to lose that information.
> I'm not quite sure what this means ? Could you give an example of how
> this looks in SQL and XML ?

In SQL, you can have something like...
   CAT_CODE              CHAR(32)                NOT NULL,
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"/>
         <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.

>> .- Added RADIX por numerical columns
> Not quite sure what you refer to ? (DdlUtils has full support for
> precision & scale for NUMERIC/DECIMAL datatypes if that's what you
> mean by radix.)

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

>> .- Added some code to handle the new definition of TIMESTAMP/DATE
>> parameters for Oracle version > 8.
> Could you give an example of this ?

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

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.
Daniel Lopez Janariz (D.Lopez@uib.es)
Web Services
Centre for Information and Technology
Balearic Islands University

View raw message