The API sets a preferred name from the synonyms if there is no name marked as preferred, so what is happening is that during the export process, the synonyms are getting marked as preferred though i wouldn't expect this to fail because this happens in the API after all validation is done, so it would only fail the next time you try to edit and save any of these concepts after the export. Apparently the logic in the API should pick the fully specified name as the first candidate to be marked as preferred before considering synonyms. I can create a ticket for this.
For the sake of getting around the problem for now, set a different preferred name(preferably the fully specified name) for one of them before exporting. Wyclif. On Fri, Sep 16, 2011 at 3:55 PM, Jeremy Keiper <[email protected]> wrote: > In my implementation, HEPATOSPLENOMEGALY has only one synonym (HSM) and > HOLOSYSTOLIC > MURMUR has two synonyms (MURMUR HSM and HSM). None are set as "preferred". > Is one assumed to be preferred by the API if none are marked? > > > Jeremy Keiper > OpenMRS Core Developer > AMPATH / IU-Kenya Support > > > On Fri, Sep 16, 2011 at 3:19 PM, Wyclif Luyima <[email protected]> wrote: > >> In the current state of the API, 2 concepts can have the same synonyms >> with the same name, what is not allowed is where 2 concepts have the same >> fully specified names OR where the 2 synonyms for the different concepts are >> within the same locale and marked as preferred. >> >> Wyclif >> >> On Fri, Sep 16, 2011 at 2:52 PM, Jeremy Keiper <[email protected]>wrote: >> >>> In our API, is there some kind of restriction that does not allow more >>> than one concept to have the same synonym? We have two concepts that both >>> use HSM as a synonym: >>> >>> HEPATOSPLENOMEGALY and HOLOSYSTOLIC MURMUR >>> >>> In both cases, the synonym HSM is correct. Does the API allow for this, >>> or is it considered an error? I ran into a problem where one of these >>> concepts was flagged as having a duplicate synonym, and it halted the >>> Metadata Sharing Module export process. >>> >>> Jeremy Keiper >>> OpenMRS Core Developer >>> AMPATH / IU-Kenya Support >>> ------------------------------ >>> 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]
