Odoo Server (MOVED TO GITHUB)

Bug #1314680
Comment #11

Comment 11 for bug 1314680

Revision history for this message

Guewen Baconnier @ Camptocamp (gbaconnier-c2c) wrote on 2014-05-09: Re: [Bug 1314680] Re: [SAAS-3] Migration script no more called on a fresh database

#11

On 05/08/2014 06:03 PM, Christophe Simonis (OpenERP) wrote:
> It is **migration** scripts. not initialisation scripts.
> They are intended to be one-shot modifications.
>
> For initialisation, use noupdate data declared in __openerp__.py
> I also remind you you can include sql files in __openerp__.py
Can you decide if they are run *before* or *after* the installation?
>
> OpenERP will automatically compute the value of the newly created stored
> function and relatedd fields. For others, the default value is used.

Are you aware that stored function fields will be computed one row at a
time, making the installation of a module nearly impossible when you
have hundreds of thousands of records?

In some cases, we *have* to help the ORM by precomputing the values of
stored function fields.

This is a good example:

https://code.launchpad.net/~acsone-openerp/account-financial-report/7.0-bug-1312732-lmi/+merge/217240

What are our possibilities?

1. Do nothing and let the stored function fields to their job:
impossible, due to the number of account move lines, it processes for
way too long
2. In init(): it was done in init() but each upgrade of the module
launch the query again. The query takes a lot of time.
3. Use a migration script that is run only at the installation of the
module, this was the better choice, until you removed it.

Also, sometimes, you have to prepare a database before the installation
of the module or run something after all is installed, and there is no
other possibilities than using migration scripts here.

>
> I taked a look at the migration scripts available on apps. Either they starts with "if not version: return", would have to, or, worst, are wrong as they recompute what must be related fields.
> I even found one that create a plpgsql function!
>
> This also error prone as every migration script would have to start with
> a check on version. C2C have already been bitten by this bug:
> https://bugs.launchpad.net/openerp-product-attributes/+bug/1259975
>
>
> ** Changed in: openobject-server
> Status: In Progress => Invalid
>

On 05/08/2014 06:03 PM, Christophe Simonis (OpenERP) wrote:
> It is **migration** scripts. not initialisation scripts.
> They are intended to be one-shot modifications.
> 
> For initialisation, use noupdate data declared in __openerp__.py
> I also remind you you can include sql files in __openerp__.py
Can you decide if they are run *before* or *after* the installation?
> 
> OpenERP will automatically compute the value of the newly created stored
> function and relatedd fields. For others, the default value is used.

Are you aware that stored function fields will be computed one row at a
time, making the installation of a module nearly impossible when you
have hundreds of thousands of records?

In some cases, we *have* to help the ORM by precomputing the values of
stored function fields.

This is a good example:

https://code.launchpad.net/~acsone-openerp/account-financial-report/7.0-bug-1312732-lmi/+merge/217240

What are our possibilities?

Also, sometimes, you have to prepare a database before the installation
of the module or run something after all is installed, and there is no
other possibilities than using migration scripts here.

> 
> I taked a look at the migration scripts available on apps. Either they starts with "if not version: return", would have to,  or, worst, are wrong as they recompute what must be related fields.
> I even found one that create a plpgsql function!
> 
> This also error prone as every migration script would have to start with
> a check on version. C2C have already been bitten by this bug:
> https://bugs.launchpad.net/openerp-product-attributes/+bug/1259975
> 
> 
> ** Changed in: openobject-server
>        Status: In Progress => Invalid
>