I agree that duplicating uuids across tables is most likely a bad idea. I think the algorithm we want to use is:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html#nameUUIDFromBytes(byte[]) This generates a “version 3” uuid. The byte array input to this method could be a string representation of the existing uuid, or a string representation of Concept Source + Concept Map. Mark From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Wednesday, April 25, 2012 12:55 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Concept map type uuids IIRC Metadata Sharing will not deal well with having multiple objects, even of different types, that have the same uuid. (My fault for telling Rafal to make it behave that way.) What are the inputs that go into producing a concept_reference_term during the upgrade? Is it just an existing concept_source + an existing concept_map? (And we still keep entities with the same uuids as the source and the map after the upgrade, right?) (Mark, my initial take is that the function should be A(ConceptSource, ConceptMap), but you may be right that it's enough to just use the map's uuid.) -Darius On Wed, Apr 25, 2012 at 9:28 AM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: There were uuids on concept_map, at least as far back as 1.6. I entered a ticket for this… I believe it is a blocker… if two different implementations have the same concept map (meaning having identical uuids), the resulting concept_reference_term on both implementations need to have the same uuid as well, to ensure consistency for purposes of metadata sharing. My suggestion to fix this (from my comment on the ticket): The uuids in the new conference_reference_term entries could be set to the corresponding uuids in the concept_map table, though this doesn't seem quite right. Alternatively, we could create an algorithm A(concept_map_uuid) -> concept_reference_term_uuid, that guarantees that if x=y then A(x) = A(y). I am not in favor of switching back to a non-standard uuid format (source code + hl7 code) The ticket is here: https://tickets.openmrs.org/browse/TRUNK-3298 From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Wyclif Luyima Sent: Wednesday, April 25, 2012 11:33 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Concept map type uuids I don't think there were UUIDs on concept maps prior to 1.9. I now recall initially the uuids for concept reference terms were a concatenation of the source code and the hl7 code of the concept source, and we changed this in favor of normal uuids, if we hadn't changed this, we would never have run into this. Wyclif On Wed, Apr 25, 2012 at 10:57 AM, Darius Jazayeri <[email protected]<mailto:[email protected]>> wrote: We might be able to manually create the UUIDs at upgrade-time, based off of the uuids of the data we're upgrading. And do that deterministically, so if you're starting from a consistent source dictionary, you end up with a consistent end product... -Darius 2012/4/25 Wyclif Luyima <[email protected]<mailto:[email protected]>> As Burke put it, we can only set predefined uuids for metadata shipping with core, and there are no concept reference terms shipping with core, that changeset is a migration script creating reference terms for existing concept mapping and these are certainly different for different implementations, we can't set uuids for what we dont know is out there in production since implementations create their own concept mappings. Though i agree this is going to pose a challenge to sync where you run the changesets for different servers and still want to have the same uuids. Wyclif 2012/4/25 Mark Goodrich <[email protected]<mailto:[email protected]>> What is happening here is that as part of the concept_map refactoring, an implementation's *existing* concept_maps are copied over to the concept_reference_term table, and a new, random UUID is created for each new concept reference term. We identified this as a problem for sync and modified the sync module to create (somewhat hacky) upgrade script that will re-standardize concept_reference_term uuids across a sync network: https://tickets.openmrs.org/browse/SYNC-265 However, as Rafal has brought this up again in the context Andy's discussion of the concept dictionary uuids, it has occurred to me that there is a large oversight in our solution--because this is as big of an issue for metadata sharing as it is for sync. That is, if there are two separate implementations using the same (ie MVP) dictionary, after upgrading to 1.9 the conference_reference_terms (the replacement for concept_maps) in the two dictionaries will have different uuids. Mark ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Wyclif Luyima [[email protected]<mailto:[email protected]>] Sent: Wednesday, April 25, 2012 8:31 AM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Concept map type uuids There are no predefined concept reference terms that ship with core like we did for map types, they are added by implementations. Wyclif On Wed, Apr 25, 2012 at 7:41 AM, Rafal Korytkowski <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: A quick look at the liquibase script shows that also concept_reference_terms have different UUIDs assigned with every update. I searched for uses of UUID(). Do we want to change that? -Rafał On 25 April 2012 01:43, Andrew Kanter <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: Although, just to be clear... the earlier email I sent refers to the UUIDs for Concepts, concept_names which are set by MVP/CIEL for the core concept tables.... do we need a discussion about these being kept stable, too? Andy -------------------- Andrew S. Kanter, MD MPH - Director of Health Information Systems/Medical Informatics Millennium Villages Project, Earth Institute, Columbia University - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology Columbia University Email: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> Mobile: +1 (646) 469-2421<tel:%2B1%20%28646%29%20469-2421><tel:%2B1%20%28646%29%20469-2421> Office: +1 (212) 305-4842<tel:%2B1%20%28212%29%20305-4842><tel:%2B1%20%28212%29%20305-4842> Skype: akanter-ippnw Yahoo: andy_kanter ________________________________ From: Mark Goodrich <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> To: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> Sent: Tuesday, April 24, 2012 7:09 PM Subject: Re: [OPENMRS-DEV] Concept map type uuids Yes: https://tickets.openmrs.org/browse/TRUNK-3235 Mark From: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> [mailto:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>] On Behalf Of Wyclif Luyima Sent: Tuesday, April 24, 2012 6:17 PM To: [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> Subject: [OPENMRS-DEV] Concept map type uuids Hi all, I recall we said on one of the dev email threads that we would set predefined uuids for concept map types before releasing 1.9, was this actually done? Wyclif ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-devel-l] ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
