As of version OpenMRS v1.5 most objects/tables have a UUID property. This property is automatically filled in for every row and is 99.9% guaranteed to be unique across the universe. The primary reason for uuids is to support the Sync Module and allow for identifying objects that are identical across different OpenMRS installations.

The uuid value will be hexidecimal digits in the form of 8chars-4-4-4-12chars (e.g 0febc204-bca1-11de-913d-0010c6dffd0f). Depending on whether mysql or java generates these (see below), the uuid could be in version 1 or version 4 respectively.

The uuid can really be any unique string within the table, but to follow conventions, all of our uuids are hex 36 characters.

All uuid columns can hold up to 38 character to accommodate MSSQL server's desire to put a curly brace ({}) at the beginning and end of the 36 chars.

Primary Key Argument

The UUID is used as a normal property of every object instead of a primary key for several reasons:

1. Using long string uuids reduces performance. Its much faster to use smaller integers for PKs
2. The uuid is a long ugly 36 character string that would not look good in urls

Initial Column Values

When upgrading a current installation of openmrs, all rows will get a uuid generated for them. If you are using mysql, then openmrs uses the uuid() method during the update to do something like:

If you are not using mysql, then there is a java routine that runs and uses the java implementation of UUID generation. This is considerably slower, I apologize that you chose an inferior dbms.

There have been issues with mysql on windows and not getting unique uuids [1] . To find those duplicates, you can run this sql:

and then to fix it you can either manually change those uuids, or you can run a more complicated sql to do it all in one go.

UUIDs and the OpenMRS API

Also in OpenMRS 1.5 there came a number of base abstract classes to define common metadata on objects. One of these objects was the OpenmrsObject. If an object extends this class and gets passed through an API method of the form of "save*(OpenmrsObject obj)", then the uuid property is automatically generated and saved along with the object. See API Save Handlers for more information about that magic.

The API uses the Java UUID class randomUUID() generation method (and so will be UUID v4 reference above).

Tables without UUIDs

There are many tables without the uuid property because they are either helper tables, mapping tables, or just used for business logic by other libraries used within openmrs.

• cohort_member
• concept_complex (extends concept table and shares uuids with that)
• concept_derived
• concept_name_tag_map (1 to many mapping from tags to names)
• liquibasechangelog (externally used by liquibase library)
• liquibasechangeloglock (created by liquibase library)
• location_tag_map
• notification_alert_recipient
• role_privilege
• role_role
• scheduler_task_config_property
• patient (extends person table and shares uuids with that...might change for 1.6)
• user (extends person table and shares uuids with that...might change for 1.6)
• user_role