Hi Dave, I'm not sure how sync handles changes that are a result of running liquibase upgrade scripts. However, from my understanding there should be no conflict of any sort in uuids for reference terms since concept_reference_term and concept_map_type are new tables that were added in 1.9. What those liquibase changesets are doing is they generate concept reference terms from your existing concept_map table, they also insert new rows in the newly created table concept_map_type.
*An overview of the changes* (You can visit additions in concept mapping attributes<https://wiki.openmrs.org/display/projects/Additional+Attributes+on+Concept+Map+(Design+Page)>for a some background info) Before 1.9 a concept map had minimal data about it and one of its properties was the sourcecode property which in the real world of concept dictionaries is not supposed to be looked at as a mere string but rather a more compound property that has attributes like name, version, description and a list of other terms that are related to it. Further more, when you create a mapping, you need to specify the map type which describes the relationship between it and the one you are mapping to in the other dictionary. Examples of my types are; replaced by, is broader, is narrower, interprets etc. This is the kind of design for concept mappings that folks that manage concept dictionaries desired OpenMRS to have and this is why the changes were made. I assumed sync has a mechanism to properly handle additions made by such upgrades scripts so that they get copied to the other servers. Wyclif On Tue, Feb 21, 2012 at 6:33 PM, Dave Thomas <[email protected]> wrote: > And it looks like the same issue is going to exist with concept_map_type? > > d > > > On Tue, Feb 21, 2012 at 3:29 PM, Dave Thomas <[email protected]> wrote: > >> Hi. I could use some help wrapping my mind around what I think is an >> incompatibility between sync and the liquibase upgrade scripts. >> >> ConceptReferenceTerm is an OpenmrsObject, meaning that sync is going to >> pay attention to it. >> >> However, in the liquibase scripts, the concept_reference_term table is >> populated with the following SQL: >> >> INSERT INTO concept_reference_term (concept_reference_term_id, >> concept_source_id, code, description, creator, date_created, uuid) >> SELECT cm.concept_map_id, cm.source, cm.source_code, >> cm.comment, cm.creator, cm.date_created, UUID() >> FROM concept_reference_map cm, concept_reference_source crs >> WHERE cm.source = crs.concept_source_id >> >> This means that the 'same' ConceptReferenceTerms are going to have >> different UUIDs between the parent and child sync servers. So if on the >> parent i modify a ConceptReferenceTerm, that's going to cause a sync >> failure -- its not going to be able to find the object. >> >> I don't know exactly what ConceptReferenceTerms do -- does it look like >> upon upgrading all child servers, we're going to have to override the >> liquibase results for this table? >> >> d >> > > ------------------------------ > 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]
