← Back to team overview

openerp-expert-framework team mailing list archive

Module "upgrade" events support on the ORM layer

 

Dear Framework-Experts:

Today Olivier commented that, as part of the solution of the bug 581137 <https://bugs.launchpad.net/openobject-server/+bug/581137>, it is planned to "/write a migration script in 5.0.12 that will force a recompute of all parent_store objects, to fix existing tables/".

I think that this kind of problem, the need to perform some migration operations when upgrading to a new version, is generic enough for us to add some support for it on the framework.

Just some use case examples:

   * The version 5.0.1 of a given module has a one2many reference
     between two objects, in the version 5.0.2 the developer realizes
     that a many2many reference instead of the one2many would be
     better. The OpenObject framework is not able to migrate the
     one2many links to the many2many table and remove the one2many
     column afterwards: A migration script would be needed.

   * The version 5.0.4 of one module had a typo on one field name, for
     example "date_finnished" instead of "date_finished". For the 5.0.5
     version the developer wants to change the name to the field
     without losing data (to be API-compatible he might also create a
     function field with the old name, etc.): he needs to run a
     migration script.

   * OpenERP version <=5.0.11 has a bug /X/ that allows the user to
     create parent accounts with an invalid type. On 5.0.12 we want to
     check the chart of accounts and set an appropriate type to any of
     such parent accounts. But obviously we don't know whether on
     future versions new types would be available for parent accounts,
     so we need a way to run the "patch script" only when upgrading
     from 5.0.X to 5.0.12, but not when going from 5.0.12 to 5.0.13,
     from 5.0.24 to 5.0.30, etc.


On all this examples something is common: the need to run some code when going from a version X (or <=X) to a version Y (or <=Y).


I know that currently we can do something like this on objects:

def init(self, cr):
   # Do something on the database connection cr...

But to me it feels not enough: It doesn't provide any info about the new&old versions to the developer, nor it allows to run scripts after every OpenERP module has been loaded.

I think we should implement something like this on the /orm_template/:


def before_upgrade(self, cr, from_version, to_version):
   """
   Called when the module is getting upgraded to a new version,
   before the tables are updated by the orm.
   """
   # Update the upgrade queue...

def after_upgrade(self, cr, from_version, to_version):
   """
   Called when the module has been upgraded to a new version,
   after the tables were updated by the orm.
   """
   # Update the upgrade queue...


The developer could then redefine such methods on his modules:


def before_upgrade(self, cr, from_version, to_version):
   """
   If going from version <= 5.0.5 to >= 5.0.6 then "do something"
   """
if from_version.major == 5 and from_version.minor <= 0 and from_version.revision <= 5 then: if to_version.major == 5 and to_version.minor >= 0 and to_version.revision >= 6 then:
          # Do something
          ...
   # Finally call the super method:
   super(self, myobject).before_upgrade(cr, from_version, to_version)

Obviously the OpenObject framework should take care of some things, like storing the old of the module on a "upgrade queue" when updating the module list. Such upgrade queue could have fields like id, module, from_version, to_version, run_after, run_before; the latest two would be used to check if the "after_upgrade" and "before_upgrade" methods should be called for this object or they had already been ran.

So, what do you think about the idea?

--
Borja López Soilán
borjals@xxxxxxxxx

Pexego Sistemas Informáticos S.L.
Avenida de Magoi 66 - 27002 Lugo (España)
Tel./Fax 982801517
http://www.pexego.es

AVISO LEGAL - CLÁUSULA DE PRIVACIDAD
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda informado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

Follow ups