Wyclif- This isn't the problem... the problem is that when the liquibase changesets creates the new conference_reference_term table entries, each entry is assigned a UUID via the UUID() function. So when you run this update on a parent and child server, conference reference terms that should be considered identical will get different UUIDs on each server.
If there was some way that mysql could generate a UUID based on some sort of hash of the record, so that the same UUID would be generated on both the parent and child, this would avoid the issue-but it seems very doubtful to me that such a function exists (or even could exist, given the way uuids work). Mark From: [email protected] [mailto:[email protected]] On Behalf Of Wyclif Luyima Sent: Thursday, February 23, 2012 11:14 AM To: [email protected] Subject: Re: [OPENMRS-DEV] concept_reference_term and sync Isn't there a way for sync to automatically compare executed changesets on the parent and child servers to ensure that they are at the same updated database version and prompt the user to perform the upgrade on the installation that is not yet upgraded. A possible way to do this would be; when exporting a package, include a hash generated from all the MD5SUMs for each executed changesets(not sure how simple this could be) and compared that to the one generated on the other server before importing any package. Wyclif On Thu, Feb 23, 2012 at 10:40 AM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: @Dave-can you enter a ticket for this? It looks like the UpgradeFormController is where this will need to add this code. It should be a "must". @Ben-we should have some procedure in place to make sure that when changes are made to the core database developers either a) do this in a way so that it won't negatively affect sync, or b) at least enter a sync ticket noting the changes that have been made and how the sync upgrade script needs to be modified accordingly. Take care, Mark From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ben Wolfe Sent: Tuesday, February 21, 2012 10:23 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] concept_reference_term and sync 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[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]
