Migrating custom fields from 5.2 to 5.4

I have a problem with migrating my current 5.2 Tryton DB to 5.4 and would like some help. One of the changes in 5.4 was the adaptation of “pycountry library” to provide updated country names using a proteus script and hence the old countries data.xml file was removed.

1- In 5.0 I had created a special subdivision classes to represent a region and district, and these were populated into the DB using another region.xml file just like the old country module. (I know in 5.4 the Subdivision class comes to replace all these classes that I created, but I didn’t know at the time I wrote my classes). So with the data.xml gone, my region.xml file will not load nor update, because it complains that it cannot find the id’s from the data.xml (from the old country module). The first thing that comes to mind is to remove the “region.xml” from tryton.cfg, but upon running trytond-admin to update my module, it generates other errors complaining about not removing a region instances from the DB, because they are being used by “party.address”. I have also extended the party.address class by adding 2 Many2One fields pointing the region and district classes.

2- So to resolve the problem, I followed the same steps int the 5.4 country’s module by creating a script that loads my list of regions and districts using the new Subdivision class. The next step was to modify my extended party.address to use the new Subdivisions instead of my old region and district classes, by adding the new fields, removing the old ones, and write some upgrade code in “def __ register__()”. However in this last step I am a bit puzzled, in that I cannot perform the migration by looking up new Subdivisions if they are not yet loaded into the DB. My script for loading the regions and districts cannot run because the module hasn’t been updated yet. So there is like a deadlock, sort of like a chicken-and-egg problem. So how should I fix this problem?

I guess you should do like we did for country, prevent XML data from being deleted on update. This will work if your script is able to find existing record and just update them instead of create a new one (like the country script does using the code).