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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: >> >>> Would a SQL View work for you? >>> >>> >>> On Thu, Dec 4, 2014 at 1:48 PM, Lars Helge Øverland <[email protected] >>> > 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 <[email protected]> >>>> 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 : [email protected] >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~dhis2-devs >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
