dhis2-devs team mailing list archive

[Murodullo Latifov <murodlatifov@xxxxxxxxx>]

There should be metadata dictionary, which generates DE, OU, period, indicator, 
category, giving each link to metadata id, the same metadata should be used for 
import/export purposes for validation, transfering new metadata objects to other 
hosts, etc. These could be achieved by slightly modifying current development. 
Any thoughts?




________________________________
From: Murodullo Latifov <murodlatifov@xxxxxxxxx>
To: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
Cc: DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
Sent: Mon, January 10, 2011 11:00:49 AM
Subject: Re: [Dhis2-devs] Revision history


Hi Bob,

Yes, also I think there should be some sort of Id independent of autogenerated 
Id for metadata objects (DE, indicator, category, period, OU). And these Ids 
should be used while importing and exporting from one location to other based on 
Metadata. Autogenerated Ids should be linked to Metadata Ids. This way we can 
guaranty uniqueness of metadata objects across implementation locations. 

For versioning hibernate audit will be fine, but it only works with annotated 
implementation of it. 


Should we put some blueprints for these?

cheers,
murod  





________________________________
From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
To: Murodullo Latifov <murodlatifov@xxxxxxxxx>
Cc: DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
Sent: Mon, January 10, 2011 10:42:41 AM
Subject: Re: [Dhis2-devs] Revision history

Hi Murod

I've been raising discussion for some time about the need for better metadata 
governance.  Currently we have a notion of metadata but no notion of whose 
metadata it is and which version it might be.  Implementators effectively do 
their best to manage this manually.

I think the latest flurry was here 
http://www.mail-archive.com/dhis2-devs@xxxxxxxxxxxxxxxxxxx/msg08466.html, from 
which I gather there is a commitment to address some of these issues in 2.0.7,  
so this might be a good time to articulate the Tajik requirements more fully.  
There are lots of ways to consider this problem, but I guess mostly it comes 
down to the level of granularity required.  I'm guessing that at first pass we 
will implement a fairly coarse grained approach, as you describe in "at least on 
each release of data dictionary".

I can't give too much thought to it right now, but I suggest we should schedule 
a fuller discussion for the end of Jan/beginning of Feb.  There are quite a few 
implications for many aspects of dhis.

Regards
Bob

PS.  In the short term your best approach might simply be to commit 
Export_meta.xml files to a local svn (or git!), tagged on release of 
datadictionary events.


On 10 January 2011 09:03, Murodullo Latifov <murodlatifov@xxxxxxxxx> wrote:

 
>  
>
> 
> 
>Hi all,
>
>We started implementing DHIS2 in Tajikistan. There are a lot to do and we are in 
>a phase of creatging data dictionary. Project manager wants to truck all changes 
>made to data elements and indicators throuout their lifetime, or at least on 
>each release of data dictionary. Are there such features currently in dhis? 
>
>Another point is to have "retired" option for all maintenance objects. Having 
>these keys we could hold or activate DE and indicators, like in OpenMRS.  
>
>
>regards,
>murod
> 
>
>  
>  
>
>  
>  
>
>_______________________________________________
>Mailing list: https://launchpad.net/~dhis2-devs
>Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~dhis2-devs
>More help   : https://help.launchpad.net/ListHelp
>
>