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