Ticket TRUNK-3235. I just set the fix version to 1.9.0.
From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe Sent: Monday, April 02, 2012 1:35 PM To: [email protected] Subject: Re: [OPENMRS-DEV] Aligning metadata UUIDs for 1.9 release Is there a ticket for this? If not, can you create one Mark? Add a fixVersion of 1.9.0 and it will get done before the next RC. Wyclif, can you create a ticket to change the default default mapping type from SAME_AS to either NARROWER or IS_A as Andy suggested on the implementer's thread? (Side note: we haven't had this many RCs since 1.2...) On Mon, Apr 2, 2012 at 11:51 AM, Andrew Kanter <[email protected]<mailto:[email protected]>> wrote: Agree... we don't want versions out there with different UUIDs... -------------------- Andrew S. Kanter, MD MPH - Director of Health Information Systems/Medical Informatics Millennium Villages Project, Earth Institute, Columbia University - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology Columbia University Email: [email protected]<mailto:[email protected]> Mobile: +1 (646) 469-2421<tel:%2B1%20%28646%29%20469-2421> Office: +1 (212) 305-4842<tel:%2B1%20%28212%29%20305-4842> Skype: akanter-ippnw Yahoo: andy_kanter ________________________________ From: Darius Jazayeri <[email protected]<mailto:djazayeri%[email protected]>> To: [email protected]<mailto:[email protected]> Sent: Monday, April 2, 2012 11:39 AM Subject: Re: [OPENMRS-DEV] Aligning metadata UUIDs for 1.9 release +1 also. -Darius On Mon, Apr 2, 2012 at 6:52 AM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: +1 On Mon, Apr 2, 2012 at 9:43 AM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: Do you guys agree this is a blocker for 1.9.0 RC2 becoming 1.9.0? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Burke Mamlin Sent: Saturday, March 31, 2012 1:17 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! Agreed. This is true for all metadata like these. Even if we don't program against specific UUID, it will help in the long run if "packaged" metadata have consistent UUIDs. -Burke On Fri, Mar 30, 2012 at 3:00 PM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: I agree... though, unfortunately, I would put this as a must-fix for the 1.9.0 release. I will enter a ticket. Mark From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ben Wolfe Sent: Friday, March 30, 2012 2:37 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! Yes, metadata added in the liquibase scripts should have set uuids instead of random ones. We've done this with conceptdatatypes, conceptclasses, etc. Ben On Fri, Mar 30, 2012 at 1:39 PM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: Just bumping this over to the dev list since I mistakenly sent it to the implementer's list. Burke or Ben, do you have thoughts on this? Thanks, Mark From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Michael Seaton Sent: Friday, March 30, 2012 12:21 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! Hi Wyclif, I would think that if core is automatically creating any metadata, it should be doing so with fixed UUIDs. It shouldn't necessarily make assumptions that these won't change (eg. there is nothing stopping an implementation from deleting and re-adding them), but it should at least make it default to the same UUID, IMHO. Mike On 03/30/2012 12:02 PM, Wyclif Luyima wrote: An implementation is only required to have at least one map type that will be used as the default for concept mappings when sharing metadata through occ and metadata from versions earlier than 1.9, and there is a global property for it. I would be fine with explicitly picking the default map type, i think should be 'same-as' and then only hard code its uuid. Wyclif On Fri, Mar 30, 2012 at 11:56 AM, Wyclif Luyima <[email protected]<mailto:[email protected]>> wrote: The reason i guess why we never hard corded the uuids is because typically implementations can create their own concept map types which will still result in having map types with differing uuids. The reason we added these is to simplify this process for them by defining the widely known/used map types. Wyclif On Fri, Mar 30, 2012 at 11:08 AM, Mark Goodrich <[email protected]<mailto:[email protected]>> wrote: I've just been looking through the 1.9 liquibase changesets that handle the migration from the old concept_source/concept_map tables to the concept_reference_* tables... I've got a question regarding changeset 20110301-1030f. This change inserts the core concept map types that are coming "pre-package" with OpenMRS... when is does so, it assigns a random UUID to each type. Don't we want to define uuids for these types beforehand, to confirm that the same concept map type has the same uuid across all implementations? I know this isn't how we've been doing things in the past, but it seems like something we really should be considering going forward. Don't we want to be able to identify that, say, concept map type "NARROWER-THAN" in one implementation is the same as the "NARROWER-THAN" type used in another implementation? This would ease Metadata sharing, for one thing, and would also ease the sharing of any other things like reports/scripts/etc that might need to be shared across implementations. My apologies if this has been debated before... I feel like I was part of discussion previously, but I can't entirely remember the reasoning for assigning random UUIDS (and obviously I wasn't convinced by that arguement... :) Take care, Mark ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Daniel Kayiwa [[email protected]<mailto:[email protected]>] Sent: Friday, March 30, 2012 7:01 AM To: [email protected]<mailto:[email protected]> Subject: [OPENMRS-IMPLEMENTERS] OpenMRS 1.9.0 RC2 Release! Greetings to everyone!!! We are happy to announce the release of OpenMRS 1.9.0 RC2 (Second Release Candidate) which you can get from the downloads page<https://sourceforge.net/projects/openmrs/files/prereleases/OpenMRS_1.9.0_RC2/>. It has a number of bugs fixed in the core application and some bundled modules. See changes since the first release candidate in the release notes<https://wiki.openmrs.org/display/RES/Release+Notes+1.9.0+RC2>. The standalone<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone> version has a new option which configures OpenMRS with the MVP/CIEL dictionary, but without any patient data. If you are familiar with OpenMRS and want to start a new system, this is a good place to start. For developers, the standalone version now lets you specify vm arguments for adjusting memory, running in debug mode, profiling with YourKit, and more as per details from here<https://wiki.openmrs.org/display/docs/OpenMRS+Standalone>. We have also improved the module to help you test this second release candidate using your existing data. Read more about it from: Release Testing Helper Module<https://wiki.openmrs.org/display/docs/Release+Testing+Helper+Module>, and download it from here<https://modules.openmrs.org/modules/view.jsp?module=releasetestinghelper>. Please help us get there sooner by giving feedback on this second release candidate. If you find any bugs, report them in our ticket tracking system<http://tickets.openmrs.org/secure/CreateIssue.jspa?pid=10000&issuetype=1>. If no major bugs are found, this will become the official 1.9.0 release in a couple of days. Upcoming End Of Life Announcements: The 1.6.x line will reach EOL with the next major release (1.9.0) A big thank you to the 70 developers and all who have, in various ways, contributed towards this release!!! Daniel Kayiwa On Behalf of the OpenMRS community -- The greatest want of the world is the want of men-men who will not be bought or sold, men who in their inmost souls are true and honest, men who do not fear to call sin by its right name, men whose conscience is as true to duty as the needle to the pole, men who will stand for the right though the heavens fall. ________________________________ Click here to unsubscribe<mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected]<mailto:[email protected]> with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]<mailto:[email protected]>?body=SIGNOFF%20openmrs-implement-l] ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' 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 ________________________________ 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]
