openupgrade-drivers team mailing list archive

[Valentin LAB <valentin.lab@xxxxxxxxxxx>]

Hi,

I was wondering what was the rationale behind running 
"sync_commercial_fields" after an update ?

To refresh memory in case, in loading:

            ...

            # OpenUpgrade: call deferred migration steps
            if update_module:
                deferred_70.migrate_deferred(cr, registry)

            ...


in openupgrade/deferred_70.py:


    def sync_commercial_fields(cr, pool):
        """
        Take care of propagating the commercial fields
        in the new partner model.
        """
        partner_obj = pool.get('res.partner')
        partner_ids = partner_obj.search(
            cr, SUPERUSER_ID,
            [], 0, False, False, {'active_test': False})
        logger.info("Syncing commercial fields between %s partners",
                    len(partner_ids))
        for partner_id in partner_ids:
            vals = partner_obj.read(
                cr, SUPERUSER_ID, partner_id, [], load='_classic_write')
            partner_obj._fields_sync(
                cr, SUPERUSER_ID,
                partner_obj.browse(cr, SUPERUSER_ID, partner_id),
                vals)

    def migrate_deferred(cr, pool):
        sync_commercial_fields(cr, pool)
        # Newly introduced _parent_store on menu items leaves gaps
        # after upgrade of other modules for *some* reason. See  lp:1226086
        pool.get('ir.ui.menu')._parent_store_compute(cr)



I mean... I understand that it need to be run after 6.1->7.0 migration, 
but won't it fail in 5.0->6.0, 6.0->6.1, ... etc..., or if it doesn't 
fail, isn't it useless ?

It'll launch also when you ask for updating a small unrelated module 
after the main migration has already been done, do we really need to get 
this run each time a small module get updated ? (This function can be 
quite long to execute...)

Why wasn't it put in the base/migrations/7.0.1.3/post-migration.py file ?

Sorry if my question has an obvious answer,

--
Valentin LAB