Hi Anaël,

The init method is too limited. The scope of the init method is limited to
a Model in an addons. The scope of a migration script is for all the
addons. For exemple, in a init method we don't know if others models from
the addons are already installed.

The possibility to use a migration script when installing an addons offers
a lot more flexibility and features than the init method and I don't
understand why you've removed this possibility.

As written in a mail to the support, in some cases, before or after
installing an addons (but only on a first install) we need to run scripts
to migrate existing data in the database according to what is expected by
our newly installed addons. (for example, insert values based on queries
for the newly created columns in the database). These scripts can be very
heavy and should in no case be run a second time.

What do you propose as an alternative to cover such needs now that it is no
longer possible via the MigrationManager?
The _init method on the BaseModel is not an alternative since it's called
whenever the addons is installed AND upgraded and the method is scoped at
the 'Model' level not at the 'addons' level.

Is the change introduced in the revision https://bugs.launchpad.net/
openobject-server/+bug/1314680  really appropriate? If a migration script
should not be used to install an addons we add a test at the beginning of
the script:
    if not version:
        return

Regards,

lmi



On Wed, May 7, 2014 at 2:15 PM, Anaël Closson (openerp) <email address hidden>wrote:

> Hi Laurent,
>
> As explained in the sent mail, you should use the init method. Using
> `migrate` for such use isn't a good idea and that's why it has been
> removed.
>
> Why ? You create an index because your module makes usage of the related
> columns. It's relevant to add the index when you install the module with
> or without the migration scripts.
>
> Beside this, having a call on migrate when installing force you the take
> care of that case in the migration scripts. Is it normal ? I don't think
> so.
>
> So, I would check if the constraint is available in pg_indexes, and if not
> add the index.
> See this message from the PostgreSQL mailing list for more information
> about it :
> http://<email address hidden>
>
> --
> You received this bug notification because you are a member of Acsone
> OpenErp Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1314680
>
> Title:
>   [SAAS-3] Migration script no more called on a fresh database
>
> Status in OpenERP Server:
>   Invalid
>
> Bug description:
>   In rev
> http://bazaar.launchpad.net/~openerp/openobject-server/saas-1/revision/4906,
> you have removed the call to the migration script on empty database or the
> first time a module is installed.
>   The change has only been applied on saas-x and trunk branches but not
> backported to 7.0.  This change is annoying since we no more have the
> possibility to use the migration machinery when installing a new module.
>  Before the change, it was easy to distinguish in the migration script,  a
> first installation of the module or a simple upgrade and therefore add code
> for each cases.
>   When a module was first installed, migration script was called with
> version set to None
>   When a module was upgraded migration script was called with the previous
> installed version.
>   Now on a fresh install we no longer have a way to use a pre/post
> installation hook.... It's really blocker for exemple when your module add
> a unique index on an already existing column and you want to update
> existing data in a way that the new constraint wil be successfully applied.
>
>   Regards,
>
>   lmi
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/1314680/+subscriptions
>



-- 
*Laurent Mignon*
*Senior Software Engineer*

*Tel : +352 20 21 10 20 32*
*Fax : +352 20 21 10 21*
*Gsm : +352 691 506 009*
*Email: <email address hidden> <email address hidden>*

*Acsone SA, Succursale de Luxembourg*
*22, Zone industrielle*
*L-8287 Kehlen, Luxembourg*
*www.acsone.eu <http://www.acsone.eu>*