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+(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 >> > > ------------------------------ > 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]
