Closed Ruhanga closed 2 years ago
@mseaton, @mks-d, after a conversation with @ibacher and following the suggestion you mentioned, I've added commits resulting in existing names having different uuids from equivalent csv names being voided with a modification on the unit tests to this effect.
My description of this change is the following: when a CSV does not set UUIDs for the concept names that it defines then it implicitly says that the UUIDs should be seeded. Therefore any existing names that match (same type, same locale, same name string) will be voided if their UUID is in contravention with the UUID specified by the CSV (that is: seeded UUID).
So yes maybe there are existing names whose UUID was once set to be something specific on purpose (and maybe other processes rely on those UUIDs to be what they are, like a sync process or otherwise) in which case the CSV redefinition of those names need to respecify those UUIDs again, otherwise they are at risk of being voided.
@mks-d and @Ruhanga - sorry I was offline for a bit. This all sounds good. Thanks for the work on this.
Hi,
I've just tested the last version 2.3.0-SNAPHOST, and I got a lot of error like:
org.openmrs.api.DuplicateConceptNameException: 'XXXXX' is a duplicate name in locale 'en' for the same concept
Before using the last version, we had 195k concept_names with 2.5k voided concept_names After restarting OpenMRS with the last iniz version, we got 7.5k voided concept names. I'd expect to have almost 195k voided concept_name.
I tried also to calculate an uuid for a concept name by using Utils.generateUuidFromObjects and I didn't get the expected result
Thanks @icrc-fdeniger for reporting this. It is possible that the new ConceptNames
s are saved before the old ones are updated which may result into the error/exception you have shared. To resolve this I've pushed a PR updating existing names before new ones are created/added.
Before
ConceptName
s were made more configurable [before #136], existingConceptName
s were detached/removed from the mainConcept
in favour of new names brought in by the config irrespective of whether the string names were equal or not. This behaviour should be maintained.Currently CSV names not configured with a uuid could match existing names with different
uuid
s and not get their uuids updated with the default seeded uuid of their associated concepts.This PR therefore allow for the CSV concept names, not configured with a uuid to be saved with a default seeded uuid from the associated concept. This may resulting in the voiding of existing equal names but with different
uuid
s in favour of the CSV defined name.