openupgrade-drivers team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 03/13/2014 04:32 PM, Valentin LAB wrote:
> Hi,
>
> I'm looking at using openupgrade. I had 2 technical questions:
>
> What are the drawbacks of merging the code with production code and
> using all this in production ?
>

Hi Valentin,

thank you for your interest in the project! Let me try to answer your
questions.

OpenUpgrade is just not maintained and tested for that so we declared
running in production out of scope for the project explicitely. Here are
the main changes in 7.0 which can impact your usage in production:

- OpenUpgrade does not raise on inconsistency between views and the
datamodel
- There have been problems with the l10n_be modules for the 7.0 edition.
As a result, some functionality in this module has been disabled in
openupgrade-addons/7.0, and l10n_be_hr_payroll, which depends on this
functionality has been set to uninstallable (something I forgot to find
a nicer solution for later on)
- We diverted the readthedocs conf.py of the official documentation in
openupgrade-server/7.0 to disambiguate with the OpenUpgrade docs for use
on readthedocs.org (not needed for 8.0 anymore)
- Any 'hidden' module dependencies are aggressively added at upgrade
time. I just today realized that this code might be run at module
uninstallation time. Who knows what might happen.
- We hardly ever update with upstream because the data model is supposed
to be stable. As a result, conflicts go unnoticed.

Making this software viable is hard work for the small community that it
has obtained. Dismissing the responsability of this software running in
production makes it a little easier. But if you can help out and
contribute with this goal in mind, feel free to pitch in.

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

By diverting cr.commit instead of removing them, we have a minimal
change and thus minimal migration effort of the custom code to the next
release of OpenERP.

> What is the general policy to follow regarding transaction ?
>
> More precisely: why the whole initilialisation / update process is not
> in one big 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.

Currently, by means of the cr.commit diversion which you observed, the
migration for each module runs in their own transaction and will be
rolled back on error. This already helps in developing migration scripts
for a particular module. After an error, you start the migration process
from the migration of this particular module, not from the very start.

What would be the benefits of running the whole update process in a
single transaction?

How would marking the modules as 'installed' only after all modules have
been migrated help? This seems problematic to me as scripts are not made
to be re-run on already migrated data.

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

OpenUpgrade does not have version 8.0 or trunk, but I am guessing you
have ported the core to OpenERP trunk/8.0, and trying to keep up with
each change in upstream incrementally. Is that correct?

Cheers,
Stefan.


-- 
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail: stefan@xxxxxxxx
tel: +31 (0) 614478606
http://therp.nl
https://twitter.com/therp_stefan