Missing field from base addons and custom modules

Hi Yann,

are you sure the post script of the base module will fail? The column will be recreated by the upgrade of the base module, even if its values will be empty.

I think you should be able to transfer the city_id from the addresses to their respective partner in a post migration script in the city module itself. Note that the base module's migration scripts store the created partner id on the old address table for these purposes.

Unrelated to the migration, is there a version 7.0 of this city module anyway? I've encountered my own problems when I tried to replace a partner address field by an unstored function field (https://bugs.launchpad.net/bugs/1253200)

Yes it fails, I just try it.

The "res.partner.address" model doesn't exists anymore in 7.0, so any 6.1 modules that change its "_columns" will likely fail because the model is not recreated by the server update with "standard" columns.

Maybe a "res.partner.address" model extracted from 6.1 should be included only for the upgrade purpose ?

About this, how this kind of changes are managed by the server? Because In my case the "city" fields becomes a related field. During the upgrade the server will recreate the column and then re-deleting it ?

Ok I found a way, I've added a "res_partner_address.py" in the "res" base addons that contains the "res_partner_address" model from 6.1 with the same values for:
_description
_name
_order
_columns

By adding this, the migration process without any error.

Hi Yann, no the model does not exist anymore. But the data is migrated to partners by the base module's migration script. You can then refer to the old res_partner_table to retrieve your city_id. Don't recreate the model in the base module please.

Hi Stefan, my explanation is maybe not clear :)

Currently I'm just targeted on official addons, I was just talking about the city module because it changed the res.partner.address model by removing the city field in my 6.1 database.

Since the res_partner_address table does not have a column named city, the function migrate_partner_address in [1] will fail.
That's why I've just recreated a "temporary" model just to allow the server to recreate the built-in res_partner_address table during the upgrade without having to change anything in the migration code.

I know that it was not a smart solution because some other modules may have added/removed some other fields that will not be treated by the migrate_partner_address but it was just quick fix for testing.

[1] /openerp/addons/base/migrations/7.0.1.3/post-migration.pi

Oh, I was mistaken when I said that the column would be recreated. Of course it won't for dropped models like res.partner.address.
So yes, you would need to recreate the column manually, to survive the SQL query that retrieves it. Currently, you could [1] do what you do, [2] alter the SQL in the base scripts or [3] add the column to the raw database using SQL. All are equally bad and cannot disguise this weakness in the OpenUpgrade architecture ;-)

Anyone has an idea how to smoothen out such troubles in the framework?

You are right, considering that OpenUpgrade is made for advanced users, maybe just adding a warning about this case in the documentation would be sufficient.