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 <wyc...@openmrs.org>

> 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 <mgoodr...@pih.org>
>
>> 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: dev@openmrs.org [dev@openmrs.org] On Behalf Of Wyclif Luyima [
>> wyc...@openmrs.org]
>> Sent: Wednesday, April 25, 2012 8:31 AM
>> To: openmrs-deve...@listserv.iupui.edu
>> 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 <ra...@openmrs.org
>> <mailto:ra...@openmrs.org>> 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 <andy_kan...@yahoo.com<mailto:
>> andy_kan...@yahoo.com>> 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: andrew.kan...@dbmi.columbia.edu<mailto:
>> andrew.kan...@dbmi.columbia.edu>
>> 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 <mgoodr...@pih.org<mailto:mgoodr...@pih.org>>
>> To: openmrs-deve...@listserv.iupui.edu<mailto:
>> openmrs-deve...@listserv.iupui.edu>
>> 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: dev@openmrs.org<mailto:dev@openmrs.org> [mailto:dev@openmrs.org
>> <mailto:dev@openmrs.org>] On Behalf Of Wyclif Luyima
>> Sent: Tuesday, April 24, 2012 6:17 PM
>> To: openmrs-deve...@listserv.iupui.edu<mailto:
>> openmrs-deve...@listserv.iupui.edu>
>> 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:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> ________________________________
>> Click here to 
>> unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>>
>> ________________________________
>> Click here to 
>> unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to 
>> unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>>
>> ________________________________
>> Click here to 
>> unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
>> from OpenMRS Developers' mailing list
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the  body
>> (not the subject) of your e-mail.
>>
>> [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
>>
>
> ------------------------------
> Click here to 
> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from 
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to 
lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the  body (not 
the subject) of your e-mail.

[mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]

Reply via email to