Re: DB schema migration

[Brett Porter <br...@apache.org>]

Hi Erik,

Took a look at this - it's not actually the jpox tables (we don't use  
the pre-configured schema), but problems when we turn on autocreation:

In an ALTER TABLE statement, the column 'INTEGER_IDX' has been  
specified as NOT NULL and either the DEFAULT clause was not specified  
or was specified as DEFAULT NULL.

we also have (which is probably because of our metadata):
In an ALTER TABLE statement, the column 'CHANGEDATE' has been  
specified as NOT NULL and either the DEFAULT clause was not specified  
or was specified as DEFAULT NULL.

So I think I'm going to do the migration tool.

- Brett

On 24/04/2007, at 7:35 AM, Erik Bengtson wrote:

> Quoting Brett Porter <br...@apache.org>:
>
>> Erik - the problem in upgrading is the changes in private tables
>> between versions of jpox that we hadn't given explicit names to. We'd
>> probably appreciate most help in future proofing our jpox use a bit
>> more in case it's internal schema changes again.
>>
>
> If you mean by private tables the JPOX_TABLES, you can drop it and  
> JPOX will
> automatically recreate if it's needed.
>

Re: DB schema migration

[Erik Bengtson <er...@jpox.org>]

Brett,

INTEGER_IDX is added automatically in two conditions (column name is
configurable):

- For a java.util.List field.
- In a JOIN table when the end of the association (element) is
embedded/serialized to a column. The column is usually a BLOB which cannot be
part of the JOIN table primary key, so INTEGER_IDX is added.

If you want keep existing data while adding these columns, you can make these
columns nullable or set a default value.

Regards,

Quoting Brett Porter <br...@apache.org>:

> Hi Erik,
>
> Took a look at this - it's not actually the jpox tables (we don't use
> the pre-configured schema), but problems when we turn on autocreation:
>
> In an ALTER TABLE statement, the column 'INTEGER_IDX' has been
> specified as NOT NULL and either the DEFAULT clause was not specified
> or was specified as DEFAULT NULL.
>
> we also have (which is probably because of our metadata):
> In an ALTER TABLE statement, the column 'CHANGEDATE' has been
> specified as NOT NULL and either the DEFAULT clause was not specified
> or was specified as DEFAULT NULL.
>
> So I think I'm going to do the migration tool.
>
> - Brett
>
> On 24/04/2007, at 7:35 AM, Erik Bengtson wrote:
>
> > Quoting Brett Porter <br...@apache.org>:
> >
> >> Erik - the problem in upgrading is the changes in private tables
> >> between versions of jpox that we hadn't given explicit names to. We'd
> >> probably appreciate most help in future proofing our jpox use a bit
> >> more in case it's internal schema changes again.
> >>
> >
> > If you mean by private tables the JPOX_TABLES, you can drop it and
> > JPOX will
> > automatically recreate if it's needed.
> >
>
>