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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]> [[email protected]
<mailto:[email protected]>] On Behalf Of Daniel Kayiwa
[[email protected] <mailto:[email protected]>]
Sent: Friday, March 30, 2012 7:01 AM
To: [email protected]
<mailto:[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
<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]
<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]
<mailto:[email protected]> with "SIGNOFF
openmrs-implement-l" in the body (not the subject) of your
e-mail.
[mailto:[email protected]
<mailto:[email protected]>?body=SIGNOFF%20openmrs-implement-l]
------------------------------------------------------------------------
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]
