Container Name Uniqueness

Turning Container Name Uniqueness ON

This constraint is set at the database level. Container Uniqueness can be turned ON by using the migrator tool, and running the optional migration step called "ContainerNameUniqueConstraints". This can be done by calling this command:

Notes:

• Of course, edit the migrator.properties file to ensure that the mode is set to "migrate" not just "validate".

• If the migrator has carried out its work successfully, the database should now have a new index present called 'unique_cnt_name'. (In psql, do \di to see indexes)

• You do not need to restart Tomcat services in order for this change to take effect

Turning Container Name Uniqueness OFF

Container Uniqueness can be turned OFF by running this SQL command:

Copy

This statement will fail if there are already any non-unique container names in the database. If it fails, you can find all non-unique names with this statement:

Copy

For each non-unique name found, you can iterate through all instances of it, and rename them so that they will be unique.

Copy

Copy

Resolving Non-Unique Container Names

When you run the above query and determine there are too many containers to hand-edit, what now?

1. Are any of the containers that have non unique names in a depleted or discarded state? If so, you can probably delete them once the customer gives the all clear:

Copy

now, what do the values for the container stateid mean? You won't find them in the database, they are hard coded as follows

Copy

Copy

Copy

Copy

Copy

Copy

Copy

Copy

Copy

Armed with this knowledge, we can refine the query to highlight containers that may be deleted with little consequence:

Copy

Copy

Copy

Notes:

1. Containers can only be deleted if they are empty

2. SQL 'IN' statements normally have a limit of 255 records, so if the the sub-select - the one in parenthesis - returns more than 255 records, your mileage may vary