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] >> > > _________________________________________ 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]
