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.
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.
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.
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.
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.
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.