Decide what happens to the 113 malformed multi-segment ids

[mosoriob]

Part of #126

Question

113 production ids hold more than one path segment after the prefix. What happens to them?

A developer created them by putting / inside the id. It is not expected behaviour. See #130 for the mechanism: model-catalog-api/src/mappers/nested-tree.ts:104 takes a client-supplied id verbatim and never checks it is a single segment.

They are the only reason the slug is not unique. Every one of the 17 collision groups holds at least one. Remove them and 5586 well-formed ids collide zero times.

The rows

Shape	Ids
.../mint/wmobley/model/<model>/variable-presentation/<name>	90
.../mint/wmobley/standard-variable/<name>	7
.../mint/wmobley/model-configuration/<name>	4
.../mint/wmobley/software-version/<name>	3
.../mint/wmobley/<name>	4
.../mint/wmobley/... other	4
.../mint/cycles_soil_c_chg/yr	1
total	113

Most sit in modelcatalog_variable_presentation. The cycles_soil_c_chg/yr row has a different origin from the wmobley rows. Check it separately.

First, find out if anything points at them

This is the fact the decision needs. Run it against TACC production.

WITH bad AS (
  SELECT id FROM modelcatalog_variable_presentation WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
  UNION ALL SELECT id FROM modelcatalog_standard_variable   WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
  UNION ALL SELECT id FROM modelcatalog_configuration       WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
  UNION ALL SELECT id FROM modelcatalog_software_version    WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
  UNION ALL SELECT id FROM modelcatalog_dataset_specification WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
  UNION ALL SELECT id FROM modelcatalog_parameter           WHERE id ~ '^https://w3id\.org/okn/i/mint/.+/'
)
SELECT 'thread_model.modelcatalog_configuration_id' AS ref, count(*) FROM thread_model t JOIN bad ON t.modelcatalog_configuration_id = bad.id
UNION ALL SELECT 'execution.modelcatalog_configuration_id', count(*) FROM execution e JOIN bad ON e.modelcatalog_configuration_id = bad.id
UNION ALL SELECT 'thread_model_io.model_io_id', count(*) FROM thread_model_io x JOIN bad ON x.model_io_id = bad.id
UNION ALL SELECT 'thread_model_parameter.model_parameter_id', count(*) FROM thread_model_parameter x JOIN bad ON x.model_parameter_id = bad.id
UNION ALL SELECT 'execution_data_binding.model_io_id', count(*) FROM execution_data_binding x JOIN bad ON x.model_io_id = bad.id
UNION ALL SELECT 'execution_parameter_binding.model_parameter_id', count(*) FROM execution_parameter_binding x JOIN bad ON x.model_parameter_id = bad.id
UNION ALL SELECT 'execution_result.model_io_id', count(*) FROM execution_result x JOIN bad ON x.model_io_id = bad.id
UNION ALL SELECT 'model_io.modelcatalog_dataset_specification_id', count(*) FROM model_io x JOIN bad ON x.modelcatalog_dataset_specification_id = bad.id;

Also check the junction tables inside modelcatalog_*. A variable presentation is referenced by its dataset specification.

Points to settle

1. Are the rows wanted at all? If they are a developer's experiment and nothing points at them, delete them. That is the cheapest answer and it removes every collision.
2. If they are wanted, are they re-minted? New id, then rewrite every reference. Map Decision 3 says existing threads and executions must keep working.
3. Does the cycles_soil_c_chg/yr row follow the same path? It has a different origin. It may come from the TriG.
4. Does the ETL recreate them? If the source TriG holds these URIs, a delete is undone on the next run. Check the TriG before deleting anything.
5. Does the cleanup ship before the slug migration, or as part of it? Cleaning first makes the migration a straight rename. It also means two production changes, not one.

Answer must record

• The reference counts from the query above.
• Delete, re-mint, or keep, for the wmobley rows and for cycles_soil_c_chg/yr.
• Whether the source TriG holds them.
• Where the cleanup sits in the cutover order, for Design the TACC production cutover and rollback #132.