[Fixes #9252] Migration form Version 3.2 to 4 – map config is missing

[mattiagiupponi]

This migration has the scope to:

• move the map blob from the old table to the new ones by copying the blob into the resource_base blob field
• move (if possible) the attributes from the mapstore_adapter_attributes table to the relative resource_base fields (title, abstract, thumbnail)
• At the end of the moving, the old mapstore_adapter table are dropped
• On top of all, there is a check to evaluate if the mapstore_adapter table is still present, if not the migration is ignored

[davekennewell]

I would suggest running the drop_mapstore2_adapter_* SQL here, before the Exception and only once the data migration has successfully completed.

Also, the exception should be focused to a specific DoesNotExist rather than a catch-anything exception that will prevent the user knowing anything went wrong with their data.

This should prevent the situation where an exception occurs between line 31 and 65, it is caught in line 67 and then continue allows the four tables to still be dropped, via lines 95 to 98, even though the data has not been successfully moved into the resourcebase yet. This situation could create a very unfortunate test of your ability to restore a database from backups (!).

[mattiagiupponi]

You are correct, the exception was permissive. I'm going to remove it so that the migration process will stop in case of an exception (any kind) and the table is not dropped.
Related to the table drop, I'll prefer to keep them into another migration operation to make it more transparent and gives a single operation his job.

[davekennewell]

OK, perfect. Yes I think that's safest. If something fails in a data migration I want it to throw an error, so I can go back & fix the data.

Thanks for your work on this!