dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

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.

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.

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.

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
developers, which is subscribed to 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"?