← Back to team overview

openupgrade-drivers team mailing list archive

Re: update_module_names questions on usage

 

Hi Sandy,

I believe that i had the same problem with my migration.
I agree with Stephan, you need to update the module name in an earlier
stage.

In my case I wrote a little python script that do a lot of process with the
differents steps :

1/ launch a 6.1 server (with my '6.1' addons with *old name*), and update
all ;
2/ do some specifics things by xml_rpc request (uninstall old module,
etc...)
3/ Stop the 6.1 server ;
*4/ execute SQL script ; *
5/ launch a 7.0-openupgrade server (with my '7.0' addons with new name),
update all and stop after init  ;
6/ launch a 7.0-OCB server and update all ;
7/ do some specifics things by xml_rpc request (install new modules, change
parameters, etc...)

I simply rename my modules in the step 4 like that :

rename_module('old_name', 'new_name')

*def* rename_module(old_name, new_name):
    req = """UPDATE ir_module_module
        SET name = '%s'
        WHERE name = '%s'; """ %(new_name, old_name)
    req += """UPDATE ir_model_data
        SET module = '%s'
        WHERE module = '%s'; """ %(new_name, old_name)
    db_tools.execute_on_database(req)


In this case, when you launch the openupgrade server the module's name are
already up to date.

It seems to work for me, so if it can help you...

Best regards.


[image: logo]  *Sylvain LE GAL
*  Service informatique
  *GRAP* SCIC SARL   *Groupement Régional Alimentaire de Proximité*   3
Grande rue des feuillants 69001 Lyon   Bureau : (+33) 09.72.32.33.17
Astreinte : (+33) 06.81.85.61.43  Site web : www.grap.coop
Twitter : @legalsylvain <https://twitter.com/legalsylvain>


2013/10/22 Sandy Carter <sandy.carter@xxxxxxxxxxxxxxxxxxxx>

> If I were to add all the related modules from mgmtsystem that were
> renamed wiki*->document*, I would be doubling the size of module_namespec
> and this is just when migrating wiki_environment_manual.
>
> A preliminary look show that the following would have to be added in base:
>     ('wiki_environment_manual', 'document_page_environment_manual'),
>     ('wiki_environmental_aspect', 'document_page_environmental_aspect'),
>     ('wiki_quality_manual', 'document_page_quality_manual'),
>     ('wiki_health_safety_manual', 'document_page_health_safety_manual'),
>     ('wiki_procedure', 'document_page_procedure'),
>     ('wiki_work_instructions', 'document_page_work_instructions'),
>
> This doesn't seem clean, I would expect OpenUpgrade to run pre-migration
> scripts (and renames) before adding available 7.0 modules as new.
>
> I tried a little hack to at least remove old module names if they've been
> added/renamed already. It fixes some problems by accepting that some
> modules
> may have been renamed or added before update_module_names is called.
> I don't know how sane this is.
>
> --- parts/openerp/openerp/openupgrade/openupgrade.py        (revision )
> +++ parts/openerp/openerp/openupgrade/openupgrade.py        (revision )
> @@ -343,9 +343,16 @@
>      :param namespec: tuple of (old name, new name)
>      """
>      for (old_name, new_name) in namespec:
> +        query = ("SELECT * FROM ir_module_module "
> +                 "WHERE name = %s")
> +        if logged_query(cr, query, [new_name]):
> +            query = ("DELETE FROM ir_module_module "
> +                     "WHERE name = %s")
> +            logged_query(cr, query, [old_name])
> +        else:
> -        query = ("UPDATE ir_module_module SET name = %s "
> -                 "WHERE name = %s")
> -        logged_query(cr, query, (new_name, old_name))
> +            query = ("UPDATE ir_module_module SET name = %s "
> +                     "WHERE name = %s")
> +            logged_query(cr, query, (new_name, old_name))
>          query = ("UPDATE ir_model_data SET module = %s "
>                   "WHERE module = %s ")
>          logged_query(cr, query, (new_name, old_name))
>
> --
> Sandy
>
> ----- Original Message -----
> From: "Stefan" <stefan@xxxxxxxx>
> To: openupgrade-drivers@xxxxxxxxxxxxxxxxxxx
> Sent: Tuesday, October 22, 2013 11:18:45 AM
> Subject: Re: [Openupgrade-drivers] update_module_names questions on usage
>
> On 22-10-13 16:28, Sandy Carter wrote:
> >      In the pre-migration (in
> openupgrade/mgmtsystem/document_page_environment_manual/migrations/7.0.1.0
> ),
> >      I have a call to this function in the migrate function.
> >          openupgrade.update_module_names(cr,
> [('wiki_environment_manual', 'document_page_environment_manual')])
>
> Hi Sandy,
>
> if I understand correctly, you call the method in the migration script
> of the module that needs renaming itself. That is too late in the
> process, the OpenERP migration manager never calls that migration script
> because it sees the module as a new, uninstalled module, as you have
> experienced.
>
> You need to update the module name in an earlier stage. In many (or
> all?) cases, there is only one practical option: put it in the list of
> known module renames in the base module's pre-migration script [1].
>
> We could simply adopt the community module renames in this script in the
> server distribution. Alternatively, a new configuration option could be
> created to process additional module renamings. Personally I would not
> mind the first option, and I think it is also the most user-friendly one
> so if no-one objects you should file an MP against the OpenUpgrade
> server distribution that adds your community module renames.
>
> Cheers,
> Stefan.
>
> [1]
>
> http://bazaar.launchpad.net/~openupgrade-committers/openupgrade-server/7.0/view/head:/openerp/addons/base/migrations/7.0.1.3/pre-migration.py#L27
>
>
> --
> Mailing list: https://launchpad.net/~openupgrade-drivers
> Post to     : openupgrade-drivers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openupgrade-drivers
> More help   : https://help.launchpad.net/ListHelp
>
> --
> Mailing list: https://launchpad.net/~openupgrade-drivers
> Post to     : openupgrade-drivers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openupgrade-drivers
> More help   : https://help.launchpad.net/ListHelp
>

References