atomica.migration.migrate¶

atomica.migration.migrate(obj, registry={'ParameterSet': [Migration(ParameterSet, 1.28.3->1.28.4)], 'ProgramSet': [Migration(ProgramSet, 1.0.8->1.0.9), Migration(ProgramSet, 1.0.9->1.0.10), Migration(ProgramSet, 1.0.16->1.0.17), Migration(ProgramSet, 1.2.0->1.3.0), Migration(ProgramSet, 1.23.1->1.23.2)], 'Project': [Migration(Project, 1.0.5->1.0.6), Migration(Project, 1.0.7->1.0.8), Migration(Project, 1.0.10->1.0.11), Migration(Project, 1.0.12->1.0.13), Migration(Project, 1.0.13->1.0.14), Migration(Project, 1.0.14->1.0.15), Migration(Project, 1.0.15->1.0.16), Migration(Project, 1.0.30->1.1.3), Migration(Project, 1.2.0->1.3.0), Migration(Project, 1.3.0->1.4.0), Migration(Project, 1.4.3->1.5.0), Migration(Project, 1.5.1->1.5.2), Migration(Project, 1.7.0->1.8.0), Migration(Project, 1.8.0->1.9.0), Migration(Project, 1.10.0->1.11.0), Migration(Project, 1.14.0->1.15.0), Migration(Project, 1.15.0->1.16.0), Migration(Project, 1.16.0->1.17.0), Migration(Project, 1.17.0->1.18.0), Migration(Project, 1.19.0->1.20.0)], 'ProjectFramework': [Migration(ProjectFramework, 1.0.15->1.0.16), Migration(ProjectFramework, 1.12.2->1.13.0), Migration(ProjectFramework, 1.23.4->1.24.0)], 'Result': [Migration(Result, 1.0.27->1.0.28), Migration(Result, 1.3.0->1.4.0), Migration(Result, 1.4.3->1.5.0), Migration(Result, 1.12.2->1.13.0), Migration(Result, 1.15.0->1.16.0)]}, version='1.28.5', gitinfo={'branch': 'Detached head (no branch)', 'date': '2024-07-01T08:48:59+10:00', 'hash': 'e19dee1'})[source]¶

Update a object to the latest version

Run all of the migrations in the list of available migrations. The migrations are run in ascending order, as long as the version is <= the migration’s original version. This way, migrations don’t need to be added if a version number change takes place without actually needing a migration - instead, when adding a migration, just use whatever version numbers are appropriate at the time the change is introduced, it will behave sensibly.

Typically, this function would not be called manually - it happens automatically as part of Project.load().

Note that this function returns the updated object. Typically the migration functions will update a object in-place, but this syntax allows migrations to replace parts of the object (or the entire object) if that is ever necessary in the future. So do not rely on migrate having side-effects, make sure the returned object is retained. In principle we could dcp() the object to ensure that only the copy gets migrated, but at this point it does not appear worth the performance overhead (since migration at the moment is only ever called automatically).

Parameters:

proj – object to migrate
version – The current version (in case this is reused in a separate module, defaults to Atomica’s)
gitinfo – The gitinfo to update (in case this is reused in a separate module, defaults to Atomica’s)

Returns:

Updated object