Perhaps this is why we originally had hardcoded the uuids to be some combination of the map name and source hl7 code? We undid that recently because it wasn't actually turning out to be unique.
Dave, this is something that should be added to the Sync Upgrade Scripts jsp page. "The scripts here should be generated on the PARENT server AFTER upgrading and run on your CHILD databases BEFORE you upgrade them to the new version". Ben On Tue, Feb 21, 2012 at 8:36 PM, Dave Thomas <[email protected]> wrote: > Hi. Thanks for the explanations. sync works through the hibernate > interceptor, so when you're running direct SQL updates, these aren't going > to get logged. At least I don't think they will, because liquibase isn't > using the openmrs services, right? And actually, if they do get logged, I > would expect liquibase to fail spectacularly on the child servers, because > many of its changes would have already been applied by sync. > > For sync, I think the rules around liquibase are that if you're adding a > row to a table that has uuids, those uuids should be hard coded into the > liquibase xml. > > I'm ok with hacking those tables manually after the upgrade, I just need > to figure out the exact routine ahead of time. > > D > On Feb 21, 2012 4:49 PM, "Wyclif Luyima" <[email protected]> wrote: > >> 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+%28Design+Page%29>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 >>> >> >> ------------------------------ >> 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]
