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]> 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 > **** > _________________________________________ 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]
