The most realistic and quick option is to change back to using sourcecode+hl7code, then the precondition for the changest will be that it doesn't get run if there are any rows with a null or blank hl7 code in the concept source table. I don't think it is quite right to duplicate uuids from the concept map table since this might break code that assumes uuids are globally unique across all tables and i think sync is one of them.
Wyclif On Wed, Apr 25, 2012 at 12:37 PM, Rafal Korytkowski <[email protected]>wrote: > If I recall right, the problem with source code + hl7 code was that it was > possible to have hl7 code null and then the changeset failed. > > -Rafał > > > > On 25 April 2012 18:28, Mark Goodrich <[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]] *On Behalf Of *Wyclif >> Luyima >> *Sent:* Wednesday, April 25, 2012 11:33 AM >> >> *To:* [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]> 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]>**** >> >> 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]>**** >> >> 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] [[email protected]] On Behalf Of Wyclif Luyima [ >> [email protected]] >> Sent: Wednesday, April 25, 2012 8:31 AM >> To: [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]>> 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]>> 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]> >> Mobile: +1 (646) >> 469-2421<tel:%2B1%20%28646%29%20469-2421<%2B1%20%28646%29%20469-2421> >> > >> Office: +1 (212) >> 305-4842<tel:%2B1%20%28212%29%20305-4842<%2B1%20%28212%29%20305-4842> >> >**** >> >> Skype: akanter-ippnw >> Yahoo: andy_kanter >> >> ________________________________**** >> >> From: Mark Goodrich <[email protected]<mailto:[email protected]>> >> To: [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]>] On Behalf Of Wyclif Luyima**** >> >> Sent: Tuesday, April 24, 2012 6:17 PM**** >> >> To: [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]?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 >> >> ________________________________ >> Click here to >> unsubscribe<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] with "SIGNOFF openmrs-devel-l" in the body >> (not the subject) of your e-mail. >> >> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]**** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> >> ** ** >> ------------------------------ >> >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> **** >> > > ------------------------------ > Click here to > unsubscribe<[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] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
