dhis2-devs team mailing list archive

[Jim Grace <jimgrace@xxxxxxxxx>]

Makes sense.


On Thu, Dec 4, 2014 at 2:29 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> Yes data synchronisation is the name of the game, but the current feature
> is a bit too crude.  I don't think it will actually prove too useful as is
> and I am not sure the wisdom of making it too sophisticated.
>
> We've been down this alley before when I embedded an apache camel engine
> into dhis2 to do this synchronisation sort of stuff - that was pretty
> flexible but a bit too cumbersome to configure so we decided it was better
> to manage this sort of thing externally.  The trouble is the use cases get
> a little complex to try and code for all eventualities - for example here
> in rwanda (where I currently am) the simplest case is to pull data from a
> dataelement group and post it on to a datawarehouse.  It gets more complex
>  when the dataelements need to be further aggregated/manipulated/mapped and
> more complex still when you get them from a "foreign" system (like ihris).
>
> So there is no easy escaping from external scripts that pull from one,
> transform/map/translate and push to another.  But I want to try as much as
> possible to pull using the api rather than through sql.  In this case
> having the DE_GROUP-xx thing will solve the problem in the future and will
> be a simple enough feature to implement.  I think the right approach
> currently is to keep chipping away at making the api as useful as possible
> by addressing use cases as they emerge.
>
> On 4 December 2014 at 21:12, Jim Grace <jimgrace@xxxxxxxxx> wrote:
>
>> Would the data synchronization feature work for you? Or some future
>> enhancement of it?
>>
>>
>> On Thu, Dec 4, 2014 at 2:05 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>> wrote:
>>
>>> Well yes I will have to resort to sql but probably just execute it
>>> directly on the database.  My intent is to take the results and post them
>>> on into another dhis2 instance.  The great advantage of the api approach is
>>> to get the period strings formatted "for free".  I suppose its not rocket
>>> science to do that externally but was hoping to avoid it.
>>>
>>> Meanwhile I was inspired by the OU_GROUP-xxx thing and will propose a
>>> blueprint for DE_GROUP-xxx.  It might also be handy to have something
>>> similar on the datavalues api, though the notion of datavalueset is quite
>>> strongly linked with a dataset rather than a data element group.
>>>
>>>
>>> On 4 December 2014 at 20:55, Jim Grace <jimgrace@xxxxxxxxx> wrote:
>>>
>>>> Would a SQL View work for you?
>>>>
>>>>
>>>> On Thu, Dec 4, 2014 at 1:48 PM, Lars Helge Øverland <
>>>> larshelge@xxxxxxxxx> wrote:
>>>>
>>>>> Hi Bob,
>>>>>
>>>>> sorry - not supported at the moment.
>>>>>
>>>>> It's however a very good idea so feel free to write a blueprint and we
>>>>> can put it in for 2.18.
>>>>>
>>>>> Lars
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 4, 2014 at 6:56 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I am trying to make a query for datavalues of dataelements in a
>>>>>> particular dataelementgroup.
>>>>>>
>>>>>> Something like the dataelement group equivalent of OU_GROUP-xxxx.
>>>>>>  de=DE_GROUP-xxx would be nice but perhaps there is a clever workaround.
>>>>>>
>>>>>> I don't really want to pull the 260 dataelement ids and form them
>>>>>> into a long query of:
>>>>>>
>>>>>> dimension=dx:xxx1;xxx2;........;xxx260
>>>>>>
>>>>>> Any suggestions of the best/simplest way?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>