Dave,

Attached are three files. -- I could not send attachments.

- A database SVN generated patch (inside it points to my workspace
path in the fs, but I'm sure you can workaround that) [1]
- The tar containing all of the files touched. [2]
- A build.xml SVN generated patch so it includes DB2 in the scripts. [3]

The patch for createdb-raw.sql did the following things:

- Remove all unnecessary nulls from column definitions
- changed one column def from default 0 to default '' (I tested this
on mySQL and it seem to cause no problems)
- moved all in-statements comments to pre-statements comments
- added a new field for additional foreign key params statements and
properly updated all db*.property files

The only thing I did not do was shorten the index names because I'm
not sure how much that could break in upgrade scripts, etc. After all
these changes, I have tested on DB2 and all my python script has to do
is shorten the index/constraints identifiers, so this is a lot of
progress.

Thanks,

Elias

[1] http://torrez.us/archives/2005/08/23/roller/patches/db2_database.patch
[2] http://torrez.us/archives/2005/08/23/roller/patches/db2_database_patch.tar
[3] http://torrez.us/archives/2005/08/23/roller/patches/db2_build.patch


On 8/23/05, Dave Johnson <[EMAIL PROTECTED]> wrote:
> 
> On Aug 22, 2005, at 8:48 AM, Lance Lavandowska wrote:
> > On 8/21/05, Elias Torres <[EMAIL PROTECTED]> wrote:
> >> - DB2 has a (seems-to-me) hard limit on identifier names for
> >> constraints and indexes to 18 chars. I had to shorten them.
> >> - It's illegal for column definitions to contain simply a "null" after
> >> the coltype (it's the default).
> 
> I knew there were still database with crazy column name limitations.
> 
> I guess the proposed "roller_" prefix is too much.
> 
> Elias: do you have a patch that goes against the 2.0 version of
> createdb.sql?
> 
> - Dave
> 
> 
> >
> > It seems to me that is the default for most DBs, so this change
> > shouldn't be an issue (removing the 'allows null' declarations).
> >
> >> - It's a column definition is of type varchar, the default value
> >> cannot be 0.
> >
> > Example please.
> >
> >> - If I use db2 -tvf createdb.sql, it seems to fail when comments are
> >> embedded in a create table definition.
> >
> > Ugh.  I suppose we could move comments to be before the table
> > definition.
> >
> >> In addition to that I had to add extra keywords to the foreign key
> >> constraints, so an extra property at the end of the contraints would
> >
> > We could add a generic transform (keyword substitution) at the end of
> > each foreign key declaration, but that seems rather hackish.
> >
> > Anyone else have comments?
> >
> > Lance
> >
> 
>

Reply via email to