Fixing inconsistency in the CVS database

[Joshocan]

There is one functionality, which prevents the mentioned workflow to solve the issue (actually it breaks whole DB). If you want to delete a SL vocabulary (let's say 5.0.1, which shouldn't exist at all, but unfortunately it's there), it will delete every SL/TL with the 5.0.x versions. So actually it removes also the previous Sl version, which leads to the inconsistent state of the DB. Please do not try on the production. But I have a solution. We will change the version of the 5.0.1 to 5.1.0. This will align with the idea of the 3 digit versioning, and also the proposed workflow can be later applied. Actually this will be much more simpler hack. Also it can stay with the 5.1.0 version in the system, if you want. At least it will be aligned with the 3 digit versioning.

[pakoselo]

@MajaDolinar @Joshocan This small patch will solve the 3 digit versioning system to have SL referenced only representing "major.minor.0" and not patch number as "1".

SET @SQL_SAFE_UPDATES=@@SQL_SAFE_UPDATES;
SET SQL_SAFE_UPDATES = 0;

UPDATE concept SET uri='https://vocabularies.cessda.eu/vocabulary/CdcPublisherNames_[CODE]?v=5.1.0' WHERE uri LIKE "%5.0.1%";
UPDATE version SET uri='https://vocabularies.cessda.eu/vocabulary/CdcPublisherNames?v=5.1.0', citation='CESSDA. (2022). CDC Publisher Names (Version 5.0.1) [Controlled vocabulary]. urn:ddi:int.cessda.cv:CdcPublisherNames:5.1.0.', number='5.1.0', canonical_uri='urn:ddi:int.cessda.cv:CdcPublisherNames:5.1.0' WHERE uri LIKE "%5.0.1%";
SET SQL_SAFE_UPDATES = @SQL_SAFE_UPDATES;

Also then can be applied the workflow, with deleting 6.0.0, 5.1.0 and recreating 6.0.0 with suggested changes. But I think, we can leave it is. It will be, with versions 5.0.0., 5.1.0 and 6.0.0 (it will be aligned with 3 digit versioning).