openupgrade-drivers team mailing list archive

[Holger Brunn <hbrunn@xxxxxxxx>]

Hi Valentin,

> What are the drawbacks of merging the code with production code and
> using all this in production ?

there are some patches specific to migrations. The openupgrade server will let 
broken views pass for example because if everything works out, they'll not be 
broken after the migration. Then there's the simple reason that it was never 
tested if the other changes have any side effects, because they are only used 
for migrations.
Further and I think more important, there's the political issue that 
openupgrade is not exactly OpenERP SA's favorite community project. So those 
changes won't ever make it into openerp standard, and I see no reason to taint 
ocb-server with controversial code bits.
Mind you that the migrate-mechanism itself is supported by the standard-
version of the server too. Openupgrade merely adds a bunch of convenience 
methods that ease writing migrations scripts a lot.

> Well, I noticed several bits of code that will cancel some actions, but
> I don't understand why these bits of code are there. Same thing for the
> way cr.commit is diverted: why not use savepoints ? Well, okay, there
> are a lot of cr.commit() in the legacy code, but they are useless, we
> can remove them it seems (or replace them with savepoints)

we added some savepoints and rollbacks where appropriate (grep for openupgrade 
in orm.py). The rationale behind defusing the cursor's transaction methods 
instead of removing their calls from code is that we want so make as little 
code changes as possible to simplify merges from upstream and porting 
openupgrade to following OpenERP versions.

> What is the general policy to follow regarding transaction ?

One transaction per module migration, see cr.commit_org() in 
openerp/modules/loading.py

> More precisely: why the whole initilialisation / update process is not
> in one big transaction ?

For example, the timezone migration for 6.1 touches every row of nearly every 
table in the database. For big databases, this might become an issue by 
itself, but probably would also for smaller databases if we stack a lot of 
other stuff onto that in the same transaction.

> For now, update scenario is really bad, and
> involves re-launching update script and slowly updating modules by
> modules the database. This update path will be unique, and won't catch
> all errors that could occurs in other slightly different paths. Not to
> mention that modules are marked 'installed' to the final version if
> their script passes, and this forces you to re-load the database in the
> first state if you just forgot some code to add in the upgrade module.

The important part here is the version number in your database. This decides 
if a migration script is run at all. So if the migration is done for one 
module, it won't be run again. But you're right, an --update=all which most 
people do triggers a module *update* (which can take a while for i.e. 
account), but no migration.
If you work on the migration script for some specific module, you'll pass --
update=$yourmodule and then you sit in just one transaction.

> I'm quite new with the code of openupgrade, and I work with
> automatically merged code between version 8.0, our code, and trunk of
> openupgrade. There's probable misconception I could have due to bad
> behaviors stemming out of bad merge. Please tell me if this is the case.

Please publish that code, it might save time when we start working on 
openupgrade for 8.0. If the above doesn't apply to your server, then indeed 
something went wrong with your merges.

Are you aware of the code sprint planned for openupgrade before the community 
days?

Regards,
Holger

-- 
Therp - Maatwerk in open ontwikkeling

Holger Brunn - Ontwerp en implementatie

mail: holger@xxxxxxxx
web: http://therp.nl

Attachment: signature.asc
Description: This is a digitally signed message part.