dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #05853
Re: [Bug 578621] [NEW] import/export based on name not ID
Hi Ola
On 11 May 2010 15:41, Ola Hodne Titlestad <olatitle@xxxxxxxxx> wrote:
> Hi,
>
> Have a look at the maintenance manual I distributed yesterday, it describes
> how to deal with metatdata conflicts in data import; the meaning of New and
> Updates and the use of compare to existing, and match new to existing.
I've had a quick look yesterday but need to study more carefully. I
think we need to tighten up a bit on the notion of metadata
governance. Establishing the human practices is of course the first
step. Having the system support those practices is next ..
>
> This way of dealing with metadata synchronisation and conflicts is well
> established in DHIS since the early versions of DHIS 1.
>
> I had some discussions with Lars last week as to how we can make the data
> import process more robust and safer, and the option to force more strict
> metadata update procedures during data import is one approach, as in not
> allowing any new or updates to metadata by default (which is useful in
> situations where you know that there should be no changes taking place at
> the lower levels). This can e.g. be triggered by import settings.
agreed
>
> The default data import now automatically adds all New meta data items,
> which is not always a good idea when there are sloppy implementers not
> paying attention to the New and Updates statistics in the import Preview
> section.
Its maybe not fair to blame the implementors entirely. If we know
what is good practice the system should support the implementors in
practicing it :-) I suspect the best setting would be for a data
import NEVER to trigger a metadata update ie. the metadata import part
of the transaction should always be in a preview/analysis mode. The
metadata import should be a separate "button" with a different
authority required in order to click it. Admittedly with everyone
logged in as admin this might have limited effect but at least we
ensure that the import of metadata is a deliberate rather than
accidental process.
Regards
Bob
>
> Ola
> ----------------
>
> On 11 May 2010 05:30, Kim Anh Vo <catakim@xxxxxxxxx> wrote:
>
>> Public bug reported:
>>
>> Currently with DHIS2.0.4, when running import/export function for DHIS2 db,
>> and through import-analysis show that identifier for daels, dataset,
>> categoryoptions, indicator, etc. is the NAME, not ID.
>> It seems messy, for example: a dataset/dael (which already exists in the
>> center db) is renamed in the local db when exported/imported into the center
>> (or upper levels db) it's recognized as a new one for importing.
>> So, if lacking user's notice/awareness, this "new" element would be added
>> into the destination db but later on when opening the equivalent session of
>> that element type (dael, sataset, ect.) conflicts occur.
>>
>> Suggestion: unify the management/strategy for import/export identifier,
>> what's it called "updates", "new"?
>>
>> ** Affects: dhis2
>> Importance: Undecided
>> Status: New
>>
>> --
>> import/export based on name not ID
>> https://bugs.launchpad.net/bugs/578621
>> You received this bug notification because you are a member of DHIS 2
>> coordinators, which is the registrant for DHIS.
>>
>> Status in DHIS 2 - District Health Information Software: New
>>
>> Bug description:
>> Currently with DHIS2.0.4, when running import/export function for DHIS2 db,
>> and through import-analysis show that identifier for daels, dataset,
>> categoryoptions, indicator, etc. is the NAME, not ID.
>> It seems messy, for example: a dataset/dael (which already exists in the
>> center db) is renamed in the local db when exported/imported into the center
>> (or upper levels db) it's recognized as a new one for importing.
>> So, if lacking user's notice/awareness, this "new" element would be added
>> into the destination db but later on when opening the equivalent session of
>> that element type (dael, sataset, ect.) conflicts occur.
>>
>> Suggestion: unify the management/strategy for import/export identifier,
>> what's it called "updates", "new"?
>>
>>
>>
>
> --
> import/export based on name not ID
> https://bugs.launchpad.net/bugs/578621
> You received this bug notification because you are a member of DHIS 2
> coordinators, which is the registrant for DHIS.
>
> Status in DHIS 2 - District Health Information Software: New
>
> Bug description:
> Currently with DHIS2.0.4, when running import/export function for DHIS2 db, and through import-analysis show that identifier for daels, dataset, categoryoptions, indicator, etc. is the NAME, not ID.
> It seems messy, for example: a dataset/dael (which already exists in the center db) is renamed in the local db when exported/imported into the center (or upper levels db) it's recognized as a new one for importing.
> So, if lacking user's notice/awareness, this "new" element would be added into the destination db but later on when opening the equivalent session of that element type (dael, sataset, ect.) conflicts occur.
>
> Suggestion: unify the management/strategy for import/export identifier, what's it called "updates", "new"?
>
>
>
Follow ups
References