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] Mobile: +1 (646) 469-2421 Office: +1 (212) 305-4842 Skype: akanter-ippnw Yahoo: andy_kanter >________________________________ > From: Darius Jazayeri <[email protected]> >To: [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]> wrote: > >+1 >> >> >>On Mon, Apr 2, 2012 at 9:43 AM, Mark Goodrich <[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]] On Behalf Of Burke Mamlin >>>Sent: Saturday, March 31, 2012 1:17 PM >>> >>>To: [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]> 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]] On Behalf Of Ben Wolfe >>>Sent: Friday, March 30, 2012 2:37 PM >>>To: [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]> 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]] On Behalf Of >>>Michael Seaton >>>Sent: Friday, March 30, 2012 12:21 PM >>>To: [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]> 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]> 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] [[email protected]] On Behalf Of >>>Daniel Kayiwa [[email protected]] >>>Sent: Friday, March 30, 2012 7:01 AM >>>To: [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]?body=SIGNOFF%20openmrs-implement-l> >>> from OpenMRS Implementers' mailing list >>>_________________________________________ >>> >>>To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to >>>[email protected] with "SIGNOFF openmrs-implement-l" in the body >>>(not the subject) of your e-mail. >>> >>>[mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l] >>> >>> >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Implementers' mailing list >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Implementers' mailing list >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Developers' mailing list >>> >>> >>>________________________________ >>> >>>Click here to unsubscribe from OpenMRS Developers' mailing list >>>>________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list > >________________________________ > Click here to unsubscribe 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]
