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]
