We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
···
ImportSummaries {
importSummaries = [ImportSummary {
status = SUCCESS,
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
···
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
As mentioned earlier. We are working on the events data sync. And this specific issue is in the /events POST API.
The idea is to retry the event data sync if there is any conflict (where essentially some data has not sycned ). Treating a CONFLICT as a SUCCESS does not sound like a good idea.
Apart from that would the /api/events POST be able to update the same event again if retried. Am coming probably from the “attributecategoryoptioncomboid” field.
Regards
Vanya
···
On Thu, May 12, 2016 at 12:26 PM, Morten Olav Hansen morten@dhis2.org wrote:
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
If this is the case, maybe after resolving the conflict of the category option identifier: U8vu31ybiD5 , Aamer will have to retry by setting the Dry Run at “No”
Hope this helps…if I’m not out of the lines…
Henri
Hi Morten
As mentioned earlier. We are working on the events data sync. And this specific issue is in the /events POST API.
The idea is to retry the event data sync if there is any conflict (where essentially some data has not sycned ). Treating a CONFLICT as a SUCCESS does not sound like a good idea.
Apart from that would the /api/events POST be able to update the same event again if retried. Am coming probably from the “attributecategoryoptioncomboid” field.
On Thu, May 12, 2016 at 12:26 PM, Morten Olav Hansen morten@dhis2.org wrote:
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
If this is the case, maybe after resolving the conflict of the category option identifier: U8vu31ybiD5 , Aamer will have to retry by setting the Dry Run at “No”
As mentioned earlier. We are working on the events data sync. And this specific issue is in the /events POST API.
The idea is to retry the event data sync if there is any conflict (where essentially some data has not sycned ). Treating a CONFLICT as a SUCCESS does not sound like a good idea.
Apart from that would the /api/events POST be able to update the same event again if retried. Am coming probably from the “attributecategoryoptioncomboid” field.
Regards
Vanya
On Thu, May 12, 2016 at 12:26 PM, Morten Olav Hansen morten@dhis2.org wrote:
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
If this is the case, maybe after resolving the conflict of the category option identifier: U8vu31ybiD5 , Aamer will have to retry by setting the Dry Run at “No”
As mentioned earlier. We are working on the events data sync. And this specific issue is in the /events POST API.
The idea is to retry the event data sync if there is any conflict (where essentially some data has not sycned ). Treating a CONFLICT as a SUCCESS does not sound like a good idea.
Apart from that would the /api/events POST be able to update the same event again if retried. Am coming probably from the “attributecategoryoptioncomboid” field.
Regards
Vanya
On Thu, May 12, 2016 at 12:26 PM, Morten Olav Hansen morten@dhis2.org wrote:
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
If this is the case, maybe after resolving the conflict of the category option identifier: U8vu31ybiD5 , Aamer will have to retry by setting the Dry Run at “No”
As mentioned earlier. We are working on the events data sync. And this specific issue is in the /events POST API.
The idea is to retry the event data sync if there is any conflict (where essentially some data has not sycned ). Treating a CONFLICT as a SUCCESS does not sound like a good idea.
Apart from that would the /api/events POST be able to update the same event again if retried. Am coming probably from the “attributecategoryoptioncomboid” field.
Regards
Vanya
On Thu, May 12, 2016 at 12:26 PM, Morten Olav Hansen morten@dhis2.org wrote:
No, I mean for the new DXF2 importer, I’m sorry (I assume you are also working on the metadata sync importer). The event importer has not had any changes done.
Thanks Morten for the insight. But we are also on a branch forked off on 2.23 and it is not giving any WARNING kind of status in our case. Any thoughts please?
On Thu, May 12, 2016 at 11:46 AM, Morten Olav Hansen morten@dhis2.org wrote:
Hi
I agree this is confusing, but I think this is also the case in our old importer. I’m not sure if we want to change it at this point (as we don’t want to break any third party clients out there).
That said, as you might know, we changed the approach a bit in our new importer, and it is much better at these kind of issues (in your case it would give status=WARNING which means please have a closer look at the report, or ERROR if all failed).
We are hoping to have proper web-api versioning coming in 2.24, which means we can potentially clean up these kinds of issues (but that part is not started yet, so let’s see).
@Abyot: are you using this returned status for anything in your EC/TC apps?
We are using /api/events to post event related data and it is being uploaded successfully. The api returns a response of type ImportSummaries which has the status of ImportSummary along with the count of data which is imported/updated.
In case of any conflicts being reported in ImportSummary, we observe that the status still shows as SUCCESS.
No, that's too much of a change. Basically I want ImportSummary/ies to be
frozen now, minor adjustments can be made, but improvements should be made
in our new reporting classes.
···
On Thu, May 12, 2016 at 10:03 PM, Markus Bekken <markus.bekken@gmail.com> wrote:
Will the https status of the whole call follow the importsummaries status?
--
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
So, I am hoping, if its a conflict you will send the ImportSummary status as Error or Warning.
And would you consider adding a first class status field on the ImportSummaries object as well. I think it makes sense, as it allows the consumer of the API to take an overall decision about the Event import.
Let me know if thats doable.
Regards
Vanya
···
On Thu, May 12, 2016 at 10:34 PM, Morten Olav Hansen morten@dhis2.org wrote:
Will the https status of the whole call follow the importsummaries status?
No, that’s too much of a change. Basically I want ImportSummary/ies to be frozen now, minor adjustments can be made, but improvements should be made in our new reporting classes.
So, I am hoping, if its a conflict you will send the ImportSummary status as Error or Warning.
And would you consider adding a first class status field on the ImportSummaries object as well. I think it makes sense, as it allows the consumer of the API to take an overall decision about the Event import.
Will the https status of the whole call follow the importsummaries status?
No, that’s too much of a change. Basically I want ImportSummary/ies to be frozen now, minor adjustments can be made, but improvements should be made in our new reporting classes.
