In a transaction, we are using “upsert” operation.
When object to be updated has an objectId, this works.
But when object to be updated doesn’t have an object Id, we get a strange transaction error: “Index 0 out of bounds for length 0”. The payload somehow includes an objectId that is the result of a previous operation in the transaction?!
In addition, logic within the transaction doesn’t seem to run properly. perhaps it is not allowed to use logic blocks in a transaction? Is there something wring with the following:
A transaction consists of one or more operations. The client-side responsibility is to package these operations into a transaction. When you call the transaction all of the operations are sent to the server at once where they are executed.
Using conditional logic to check the result of an operation before an operation ran will not work. As a result, what you’re trying to do here will not be executed as intended (for the reason that when the
if block is executed, the transaction is not even started yet).
Yes, I got the feeling in the hours of struggle that there was kind of a time warp happening, that things happen all at once. But is there no way to construct a transaction such that the result of a find operation determines what the next operation does? I mean specifically: if nothing found — create, otherwise — update? Seems like it should be possible
No, you can not rely on operations results until you run the transaction. The idea of the transaction API is to execute a group of operations (requests) and if some of them fail the server rolls back all operations in the transaction.
if nothing found — create, otherwise — update
it sounds like you are looking for an Upsert Operation, don’t you?
Yes, we just want to upsert… but for that, we first need to get an objectId for the object to be upserted (by running a “find”). If no objectId exists, we create a new object, if it does exist we modify existing object. Sounds like we need to do the find before the transaction, in a separate API call.