Reverting Error State¶
By default, if you execute a DELETE
request against any entry in ErrorArchive
using the deleteEntity()
method, it reverts all error states and discards all data from ErrorArchive
.
In addition, the requests associated with entries in ErrorArchive
are removed.
After the DELETE
request, all entities or relationships in error state are reverted so that they appear as though the failed requests were never applied, and are no longer in error state. The ErrorArchive
entity set is empty.
DataQuery errorArchiveQuery = new DataQuery().from(errorArchiveSet);
// Get the list of errors in the ErrorArchive
EntityValueList errors = eventService.executeQuery(errorArchiveQuery).getEntityList();
if (errors.size() > 0) {
eventService.deleteEntity(errors.get(0));
}
let errorArchiveQuery = DataQuery().from(errorArchiveSet)
/// Get the list of errors in ErrorArchive
let errors = try eventService.executeQuery(errorArchiveQuery).entityList()
if errors.length > 0 {
/// Delete the first error
try eventService.deleteEntity(errors.first())
}
In case you want to delete individual ErrorArchive
entries (in other words, individual failed requests) instead of letting one deletion revert everything, you need to turn this functionality on by calling OfflineODataParameters.setEnableIndividualErrorArchiveDeletion(true)
(in Swift source code, setting OfflineODataParameters.enableIndividualErrorArchiveDeletion = true
) when opening the offline store with parameters.
With the functionality turned on, deleting an individual failed request from ErrorArchive
causes that request and any following requests in the request queue (sent or unsent) that depend on the failed request, to be deleted as well.
It is important that you understand the difference between having the support or not. For example, if the following requests are made by an application, some of which will fail when they are executed on the back end:
- Request #1: Update
event101
, which will fail in the back end. - Request #2: Update
event102
, which will fail in the back end. - Request #3: Update
event101
again.
Now, upload requests #1 to #3. Then, continue to make another request:
- Request #4: Update
event102
again
During the upload, requests #1 and #2 fail due to issues in the back end. Request #3 (the second event101
update) will not be sent to the back end at all because a request it depends on (the first event101
update) failed. At the end of the upload, ErrorArchive
has three errors, one for each failed request in the upload.
With the functionality turned off (enableIndividualErrorArchiveDeletion
set to false
), deleting any entity from ErrorArchive
results in requests #1, #2, and #3 being removed from the request queue, but will leave request #4 in the request queue unchanged.
With the functionality turned on (enableIndividualErrorArchiveDeletion
set to true
), the application decides which failed requests to delete explicitly. There can be different scenarios:
- If the application chooses to delete failed request #3, it's the only one that's deleted, because no other requests after it in the request queue depend on it.
- If the application chooses to delete failed request #1, both request #1 and request #3 are removed from the request queue because request #3 depends on request #1.
- If the application chooses to delete failed request #2, both request #2 and request #4 are deleted because, even though request #4 has not yet been uploaded, it depends on request #2.
Note
The ErrorArchive
entity set is offline-specific; there is no need to upload after invoking deleteEntity()
.