Closed AleksandrRogov closed 1 year ago
The idea is to add an additional property inChangeSet
to RequestBase
interface that will default to true
. It has to be set to false
by the developer to execute an operation individually inside a batch request.
There are other ideas that I have but I doubt that I am going to include those in a release of v2:
nonAtomic
property to startBatch
. By default it will be false
.
If set to true
- all operations in a batch request will be executed individually, unless inChangeSet
has been set to true
by the developer for that operation. Basically, nonAtomic = true
reverses the default value for inChangeSet
property to false
when it's not set.startChangeSet
and endChangeSet
which will have an effect only if nonAtomic
in startBatch
has been set to true
. The idea here is to have this function for future major versions of the library and deprecate the current default logic where all operations (except for GET) are automatically included in the change sets (this logic was introduced in v1.5.0 when batch operations were added and I currently consider this logic to be incorrect). The correct way is to have individual operations in a batch request by default and if needed they can be included in the change sets by calling startChangeSet
function or setting inChangeSet
to true
.
Consequently, we should deprecate nonAtomic
property in a Batch Request and remove with the next major version.This ideas are up to debate. If anyone has any thoughts about it - let me know.
Right now any POST, PUT, PATCH and DELETE will automatically be included into a Changeset which may not be useful in all situations.
Here are the tasks related to the issue:
The new logic must not break existing logic of converting requests into a changeset by default. Mainly because it's going to be a very significant breaking change.