Question

batch updates using atomicity

14:17 Sep 25, 2023

Hi all,

Does anyone have experience using batch updates via the API and atomicity function.

I have followed the documenation similiar to the below, both with and without the prefer header. My understanding is that if one of the requests below fail, then any successful ones in the array will be rolled back. However, this doesn't seem to be happening.

On use of the below, if the second POST fails, the first POST still appears in the database.

Any help greatly appreciated

{
	"requests": [
	{
		"method": "POST",
		"atomicityGroup": "g1",
		"url": "City",
		"id": "t3",
		"body": {
			"Id": "62f9bc01-57cf-4cc7-90bf-8672acc922e3",
			"Name": "Spokane"
		},
		"headers": {
			"Content-Type": "application/json;odata=verbose",
			"Accept": "application/json;odata=verbose",
			"Prefer": "continue-on-error"
		}
	},
	{
		"method": "POST",
		"atomicityGroup": "g1",
		"url": "City",
		"id": "t2",
		"body": {
			"Name": "Texas"
		},
		"headers": {
			"Content-Type": "application/json;odata=verbose",
			"Accept": "application/json;odata=verbose",
			"Prefer": "continue-on-error"
		}
	}
	]
}

5 comments

Anhelina

17:20 Sep 27, 2023

Hello Harry,

Batch request is simply a set of separate requests for optimization of a call process. If the first transaction succeeds but the second fails, the database updates made in the first transaction aren’t rolled back. Here you can find useful information how to use batch in the right way:

http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-…

Best regards, Anhelina

Harry

22:59 Sep 27, 2023

Anhelina,

Thanks Anhelina, I'm not sure that's quite right though... Here is an extract from the link you provided:

The value of atomicityGroup is a string whose content MUST NOT be identical to any value of id within the batch request, and which MUST satisfy the rule request-id in [OData-ABNF]. All request objects with the same value for atomicityGroup MUST be adjacent in the requests array. These requests are processed as an atomic operation and MUST either all succeed or all fail. Requests within an atomicity group that may have otherwise succeeded but are rolled back due to failure of another request in the same atomicity group MUST return a status code of 424 Failed Dependency.

Anhelina

14:18 Oct 20, 2023

Hello Harry,

You're right, it's impossible to implement such request. We made a task for R&D department to add Odata functionality in Creation and allow atomicity in future releases.

Best regards, Anhelina!

Vojtěch Šalda

20:01 Jul 26, 2024

Anhelina,

Hello, I would love to know whether there are any updates regarding this issue? Can't find anything about atomicityGroup nor batch requests in release notes of versions 8.1.1 to 8.1.4 that were released after the last comment in this thread. Also when using atomicityGroup in batch requests with version 8.1.2, no rollbacks are made upon failure. Thank you for any information.

Best regards,
Vojtěch.

Yuliya Gritsenko

19:34 Aug 05, 2024

Vojtěch Šalda,

Hello,

Unfortunately, there is no exact ETA on this matter.

The R&D team is aware of this issue and working on adding Odata functionality in Creation and allow atomicity in future releases.

Best regards,
Yuliya

Show all comments