NamespaceRoleMapping (v1) and NamespaceRoleMappingV2 (v2) role mappings have incompatible formats.
v1 allows regexes and has no uniqueness constraints.
v2 requires concrete namespace ids to be provided and requires the role to be unique for each pair of namespaces (namespace_id, other_namespace_id).
Because of this, we cannot transparently migrate users to the v2 table:
regexes inserted into the NamespaceRoleMapping.entity field can potentially be invalid, e.g., "*" will fail because there's no character to repeat
multiple roles can be assigned to the same namespace.
Value and/or benefit
Since the migration code copying data from v1 to v2 might fail, we won't migrate users automatically.
Otherwise, they won't be able to migrate to v2 due to errors.
However, I'll provide standalone code in the documentation for users who want to migrate their data and are ready to resolve SQL issues that might arise during migration.
This code will just be a function they could call and will be tested on potentially problematic cases.
The high-level view of the migration algorithm is as follows (I have a WIP implementation locally):
get v1 role mappings
find all namespaces that match the namespace regex (everything that's before / in entity)
for each of these namespaces, create a role in the v2 role mappings table.
Notes:
regexes can be invalid, which will cause an error (this can be skipped while printing which data is skipped)
a uniqueness constraint can be violated in (these entries can be skipped as well)
in the v2 table, relationship between namespaces is reversed. That is, for v1, namespace gets access to some other namespace by specifying the other namespace in the entity field. In v2, namespace_id will be the other namespace that will provide access to itself by specifying namespace in other_namespace_id.
Feature description
This is intended as a follow up to https://github.com/conda-incubator/conda-store/pull/607.
NamespaceRoleMapping(v1) andNamespaceRoleMappingV2(v2) role mappings have incompatible formats.namespace_id,other_namespace_id).Because of this, we cannot transparently migrate users to the v2 table:
NamespaceRoleMapping.entityfield can potentially be invalid, e.g.,"*"will fail because there's no character to repeatValue and/or benefit
Since the migration code copying data from v1 to v2 might fail, we won't migrate users automatically. Otherwise, they won't be able to migrate to v2 due to errors. However, I'll provide standalone code in the documentation for users who want to migrate their data and are ready to resolve SQL issues that might arise during migration. This code will just be a function they could call and will be tested on potentially problematic cases.
The high-level view of the migration algorithm is as follows (I have a WIP implementation locally):
/in entity)Notes:
entityfield. In v2,namespace_idwill be the other namespace that will provide access to itself by specifying namespace inother_namespace_id.Anything else?
No response