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