Wycliff, At least for those using CIEL dictionary we need to ensure the UUIDs are stable.
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] Mobile: +1 (646) 469-2421 Office: +1 (212) 305-4842 Skype: akanter-ippnw Yahoo: andy_kanter >________________________________ > From: Wyclif Luyima <[email protected]> >To: [email protected] >Sent: Wednesday, April 25, 2012 10:51 AM >Subject: Re: [OPENMRS-DEV] Concept map type uuids > > >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] >> > >________________________________ > Click here to unsubscribe 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]
