bulkUpdate for list of objects by objectIds

Suggestions/Ideas
1

current bulkUpdate needs where clause and make update by single parameter object. I need something more similar to how bulkCreate works - you provide list of objects with ObjectIds and other fields:
var persons = [
{ objectId:“abcd1”, “age”:24 },
{ objectId:“abcd2”, “age”:34 }
];
Backendless.Data.of(“Person”).bulkUpdate(persons)

2

Hi Yuriy,

thank you for the suggestion, this sounds like a great idea. We will review it internally and consider adding to the roadmap.

Regards,
Mark

3

Fully agree with Yuri!!!
It would be great and logical to have such an opportunity.

We have to update thousands of records on our project. And this should be done as quickly as possible. To bypass the current constraint, we must first delete all entries using bulkDelete and then using bulkCreate we restore all records with last updates. It doesn’t look very good, and not as efficient as it could be.

4

Hey @mark-piller, was this suggested feature ever implemented? I cannot seem to find it in the documentation for the REST API. I need to update multiple objects with different values, but as of right now, I can only update multiple objects with the same value.

I am forced to do a bulkDelete followed by a bulkCreate using the Transactions API. However, this approach will still not work at all if the objects being “updated” happen to have a 1:1 relation field, since it is not possible to do a bulk operation for setting 1:1 relations either and doing it individually within a transaction wouldn’t be possible due to the limit on the number of operations.

Not having bulk updates with different data would be quite deal-breaking for us, as our app functionality requires us to be able to update any number of objects within a table at the same time but with unique values. Please let me know. Thanks.

5

How about adding multiple update operations into a single transaction?

6

We initially tried that but we quickly realised it wouldn’t work for us as the number of operations within a single transaction can vary due to the user controlling the input for the number of objects that would be updated.

Even if we enforce a reasonable limit, it wouldn’t be economically feasible for us at the moment (in our case, that limit would need to be ~20 objects, which means we would need at least 25 operations). Even if we would rarely expect our users to go beyond ~10 inputs, having an arbitrary limit feels like poor UX caused by a somewhat artificial constraint.

Why would it not be possible to update multiple objects in bulk similar to how we can create them in bulk?

7

Hi Juan,

Thank you for sharing that additional information. Updating different objects in bulk would mean that the implementation needs to cycle through the objects and issue separate update requests for each. This goes against the general principle of our API design where a single API request results in a single database query. This is the reason why it hasn’t been implemented. There are several options available for you:

  1. Create an API service that would accept a collection of objects to be updated. The service then would “batch” the updates into separate transactions where you can control the number of operations

alternatively:

  1. Do the same thing as above, but without an API service, in other words, implement the batching on the client

alternatively:

  1. Purchase additional operations for transaction function pack from the Marketplace. Each purchase increases the number of operations by 5.

Regards,
Mark

8

Hey Mark,

I would have thought that updating multiple records in a single operation was perfectly doable in either SQL or NoSQL engines?

Regarding the options you suggested, our primary concern with doing batches or loops has been that if one of the requests fails we now have partial updates/dirty data. Is there a way to prevent that using either of your first two proposed solutions?

At the moment, option 3 is not available for us.

Thanks!

9

Hi Juan,

Unfortunately, a single SQL query cannot update two different database records (unless you do it using the current bulkUpdate approach).

The only way to ensure that either all update requests go through or none is by putting them all into the same single transaction. Otherwise, you may have the following situation:

  1. TX1 - success
  2. TX2 - success
  3. TX3 - failed
  4. TX4 - pending (waiting to be executed in your code)

Since TX3 failed, then any changes made by TX1 and TX2 need to be rolled back, however, since both transactions have already been committed, the rollback needs to be done manually (PIA).

Btw, exactly the same problematic scenario would exist if the API you’re asking about were available - each object is updated with a separate query and if one fails, all others updated prior to the failed one need to be rolled back - same painful result to deal with.

Regards,
Mark

1 Like
10

Fair enough, as suggested I ended up implementing logic in my application to roll back any changes. Thanks for the help @mark-piller.