EncounterType has a unique key constraint on its name field?

Development
1

Hi all,

Just noticed that the EncounterType has a unique key constraint on its name field. See EncounterType.hbm.xml#26

This issue with this constraint is that it prevents to create an encounter type with the same name, even if its homonymous entity is retired.

This is the ticket that introduced the change: https://issues.openmrs.org/browse/TRUNK-4044

Such constraint is not applied to Visit Types.

Additional research found that few entities have such constraint as well:

Is there a rule to decide when we should make an entity name unique?

(cc @mksd, @dkayiwa, @mogoodrich)

2

I personally thought that if you want to reuse the same exact name, you would simply unretire the existing one. :slight_smile:

3

Well, it happens that I need to retire a specific Encounter Type to make a new one that has a UUID I know (hardcoded via Iniz config).

And since neither visit types nor locations have such constraint, I am a bit surprised to see this behavior for encounter types.

4

I think we just forgot adding them to that other metadata. :slight_smile:

5

I agree with @dkayiwa. I think it’s generally expected that names will be unique, though because it has been sporadically enforced it’s known that this can’t be universally relied upon. I’d assume we should keep names unique and that further constraints may be added to enforce this in a later release. For your use case, your best options are probably either migrate to a new uuid or rename the existing encounter type by appending " -v1" or “-retired” or something to the name.

6

Agree with @dkayiwa and @mseaton!

7

I agree that the name should be unique among all non-retired entities. But wouldn’t expect the uniqueness constraint to lookup even in the retired ones.

In my opinion the natural behavior is one similar to Concepts, where the FSN is a unique key, only among non-retired concepts.

8

So @mksrom would you want the database unique constraint to combine two fields (name, retired) instead of just (name)?

9

It’s nice to have db level constraints to help enforce data integrity. Combining name & retired into uniqueness, though you could have obscure errors trying to retire a resource that’s name matches a previously retired resource. And what happens if you try to retire a resource with a name previously used and retired?

How about keeping name uniqueness in the db and have the API help by adding “ (retired)” or “(retired #2)” to the name when retiring and removing it (adding a number if needed for uniqueness) when unretiring?