[OGo-Users] Migration of ogo

[Helge Hess]

On 03.04.2008, at 18:27, Peter Brueckner wrote:
> My idea for upgrading a database application was
> wrong. I thougth it wouldt be better to use the
> new schema and the old data.

Usually thats not the worst idea. But the OGo schema-setup does not  
only add the raw schema, but also the core data items needed.
Maybe one could separate those two steps (but then installs are more  
error prone ...).

Anyways, upgrading a schema incrementally is always better. Eg if a  
column got renamed, your dump wouldn't even load (while an ALTER TABLE  
would properly do the task). Not that we want to do such incompatible  
changes.

> The UTF-Conversion was not needed because of dump
> (LATIN1) and starting ogo with PGCLIENTENCODING in
> the provided start-script.

Si.

>>>
> The next mistake was to think about using the constraints file.

I think we agree that the contraints file is b0rked. This is a bug,  
there is nothing wrong with using constraints.
(though OGo itself can deal with 'broken links' in quite a few places,  
so not ALL constraints might be necessary)

>>
> That is not the problem. The problem is the foreign key in
> the refering table. If you say
>  "ADD constraint telephone2company foreign key(company_id) references
>  company(company_id)"
> you will not get any telephone into the db because there are no  
> companies!

BTW: company is the basetable for person and enterprise. If you  
perform a SELECT on it, it works as expected.

> There are only persons, enterprises.... So i cant see a way for this
> kind of foreign key until this is repaired in postgres.

I think you should be able to emulate that REFERENCES constraint with  
a CHECK constraint. Which someone ;-) should do and add that to the PG  
constraints file, so that it properly works.
Or at least remove the constraints which do not work.

>>
> So a little comment in the file would be nice. f.e "Please dont use  
> this file"

Nah, the file should be fixed.

>>>
>> But usually its just a dump/load/done. So far the DB schema has been
>> superstable:
> Thats why a complete dump and restore works. But if are
> sometimes schema changes?

Guesswork. We'll provide from-to update scripts if something needs an  
upgrade (in fact I do have a few enhancements to the DB schema pending).

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/