Leave the global property but set its value to IS_A by default instead of SAME_AS.
Ben On Mon, Apr 2, 2012 at 1:55 PM, Wyclif Luyima <[email protected]> wrote: > @Ben, do you mean we get rid of the global property? And always set it to > IS_A, currently the way it is, you have to set a value for the global > property otherwise the mapping gets rejected if it has no map type. > > Wyclif > > > On Mon, Apr 2, 2012 at 1:35 PM, Ben Wolfe <[email protected]> wrote: > >> 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]>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] >>> 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<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' mailing list >>> **** >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-implement-l>from >>> OpenMRS Implementers' 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 >>> >>> >>> ------------------------------ >>> 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]
