Added unique constraints for entities

[aklochkova]

Fixes OHDSI/Atlas#1338

[pavgra]

Why constraint names differ across databases? This would complicate further migrations. Pls, use consistent naming. I would go for a pretty common prefix - uq_

[chrisknoll]

Trying to embed the ohdsi schema (which is a dynamic/user defined value) into the constraint name is a little complicated, isn't it?

Since we own the schema, we can ensure that the unique constraints are unique to the schema, right? If so, couldn't we just resort to simple naming conventsions like UQ_Table_Col type of formats, and not build dynamic sql in the migrations script?

In addition, when we are troubleshooting problems people may have with these constrtaints, if we name them directly, we'll be able to offer assistance. If it's based on some application config, it becomes a barrier for us to tell them which constraints to check/disable.

[anthonysena]

Agreed @chrisknoll - I'm updating the scripts to remove that from the constraint name as well as make some updates for the SQL Server migration script as I was having challenges running things against our SQL Server 2012 environment.

[anthonysena]

@pavgra - some notes on my changes and from my side this is ready to merge in.

The SQL Server migration script was problematic in our environment since chaining together the stored proc calls was not working well. I revised this script to use straight UPDATE statements to increment any duplicated names based on the row_number() to make them unique and then apply the constraints.

The PostgreSQL script was also causing me challenges (I'm on v9) and so I revised that a bit to make sure the procedure call had the ohdsiSchema prefix and increased the size of the duplicate_names column to accommodate values > 100 characters.

Per @chrisknoll's feedback I removed the ohdsiSchema name from the constraint across all 3 migration scripts.

[chrisknoll]

Branches should be deleted after merge, please.

[aklochkova]

@anthonysena, hi! there's a bug after your changes
for example, we have the following data in concept_set table:

after completing this UPDATE operation

WebAPI/src/main/resources/db/migration/sqlserver/V2.8.0.20190424150601__add-unique-name-constraint-to-entities.sql

Line 3 in fc12285

UPDATE ${ohdsiSchema}.concept_set

we have the following state:

so, rows with duplicate names (№1 and №2) appears and unique constraint can't be added.

I managed this case in my previous procedures (rename_cs_names), it should be something like

[anthonysena]

Thanks @aklochkova - you are absolutely right. Sorry to have missed that. Let me open an issue so that we can fix this migration script.