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> > Office: +1 (212) 305-4842<tel:%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] > _________________________________________ 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]
