← Back to team overview

openupgrade-drivers team mailing list archive

Re: update_module_names questions on usage

 

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


Follow ups

References