@Pedro, one last comment: so I see that in http://bazaar.launchpad.net/~openerp-spain-team/openerp-spain/7.0/view/head:/l10n_es_toponyms/wizard/l10n_es_toponyms_zipcodes.xml you went for the denormalization of the cities into the zip codes. But as you explained https://code.launchpad.net/~savoirfairelinux-openerp/partner-contact-management/city-move/+merge/196023/comments/461148, denormalization wouldn't be required, and here in Brazil we will not got this way to avoid 6 millions of res.better.zip (we will use an other table or converter as we do today).
However I'm not too sure res.better.zip will then semantically means the same thing for us: for me picking a res.better.zip is really "picking a city" while for you as your cities are denormalized into that table it means "picking just a zip code", not a city (like your records city_ES_1 city_ES_2 point to the same city in that XML file)... Then, we will really need to have a semantic convergence of that res.better.zip toward a city else our verticals won't be compatible and aside from using the same base module we will not have fixed everything. It means you will need to change your Spanish localization to stop using denormalization here. Do you agree with this statement? If I have a suggestion for your localization, transform that l10n_es_toponyms_zipcodes into an SQL file, it will load way faster. We did the same move here, the win was huge. Regards -- https://code.launchpad.net/~savoirfairelinux-openerp/partner-contact-management/city-move/+merge/196023 Your team Savoir-faire Linux' OpenERP is subscribed to branch lp:~savoirfairelinux-openerp/partner-contact-management/city-move. -- Mailing list: https://launchpad.net/~savoirfairelinux-openerp Post to : [email protected] Unsubscribe : https://launchpad.net/~savoirfairelinux-openerp More help : https://help.launchpad.net/ListHelp
