Hey. I will file a ticket. However, I think the easiest easy to deal with this is going to be to just recreate the child servers after upgrading the parent. This way, we don't have to deal with overwriting uuids, and it provides us with a sanity check by cleaning up any differences that may have arisen during our last two years of using sync against the 1.6 branch...
D On Feb 23, 2012 9:10 AM, "Mark Goodrich" <[email protected]> wrote: > 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]> 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]] *On Behalf Of *Ben Wolfe > *Sent:* Tuesday, February 21, 2012 10:23 PM > *To:* [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]> 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 > **** > > **** > ------------------------------ > > 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 > **** > ------------------------------ > 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]
