aiida.manage.database.integrity package

Methods to validate the database integrity and fix violations.

aiida.manage.database.integrity.write_database_integrity_violation(results, headers, reason_message, action_message=None)[source]

Emit a integrity violation warning and write the violating records to a log file in the current directory

  • results – a list of tuples representing the violating records

  • headers – a tuple of strings that will be used as a header for the log file. Should have the same length as each tuple in the results list.

  • reason_message – a human readable message detailing the reason of the integrity violation

  • action_message – an optional human readable message detailing a performed action, if any


Generic functions to verify the integrity of the database and optionally apply patches to fix problems.


Check whether database table contains rows with duplicate UUIDS.


table – Database table with uuid column, e.g. ‘db_dbnode’


IntegrityError if table contains rows with duplicate UUIDS.


Retrieve rows with duplicate UUIDS.


table – database table with uuid column, e.g. ‘db_dbnode’


list of tuples of (id, uuid) of rows with duplicate UUIDs

aiida.manage.database.integrity.duplicate_uuid.deduplicate_uuids(table=None, dry_run=True)[source]

Detect and solve entities with duplicate UUIDs in a given database table.

Before aiida-core v1.0.0, there was no uniqueness constraint on the UUID column of the node table in the database and a few other tables as well. This made it possible to store multiple entities with identical UUIDs in the same table without the database complaining. This bug was fixed in aiida-core=1.0.0 by putting an explicit uniqueness constraint on UUIDs on the database level. However, this would leave databases created before this patch with duplicate UUIDs in an inconsistent state. This command will run an analysis to detect duplicate UUIDs in a given table and solve it by generating new UUIDs. Note that it will not delete or merge any rows.


dry_run – when True, no actual changes will be made


list of strings denoting the performed operations, or those that would have been applied for dry_run=False


ValueError – if the specified table is invalid

Generic functions to verify the integrity of the database and optionally apply patches to fix problems.


Try to infer a calculation entry point name for all the calculation type strings that are found in the database.

Before the plugin system was introduced, the type column of the node table was a string based on the base node type with the module path and class name appended. For example, for the PwCalculation class, which was a sub class of JobCalculation, would get as its type string. At this point, the JobCalculation also still fullfilled the role of both the Process class as well as the Node class. In the migration for v1.0.0, this had to be migrated, where the type became that of the actual node i.e. node.process.calculation.calcjob.CalcJobNode. which would lose the information of which actual sub class it represented. This information should be stored in the process_type column, where the value is the name of the entry point of that calculation class.

This function will, for a given set of calculation type strings of pre v1.0.0, try to map them on the known entry points for the calculation category. This is the union of those entry points registered at the AiiDA registry (see the mapping above) and those available in the environment in which this function is ran.

If a type string cannot be mapped onto an entry point name, a fallback process_type string will be generated which is based on part of the old type string. For example, calculation.job.unknown.UnknownCalculation. would get the process type string ~unknown.UnknownCalculation.

The function will return a mapping of type strings onto their inferred process type strings.


type_strings – a set of type strings whose entry point is to be inferred


a mapping of current node type string to the inferred entry point name