Is there a way to make something like atomic transaction in Retool?
I have 3 queries that conduct 3 steps one by one:
Add a record to the db.
Take and calculate data from the db taking into account the new entry, that was created on step 1.
Send the data to the REST API endpoint.
The thing is in Retool any of this query may work or not. So overall the probability that all this queries work together and do the trick is (as I have investigated) about 80%. This is not enough to consider the application workable.
The question is: is there a way to make this queries work all together or no one of them? E.g. if the 3rd query breaks then the first query don't add a new entry to the db and the second also does nothing. Because now if there is an error in 2nd or 3rd steps the entry is created but it isn't sent to api. So this creating is useless in fact.
I want to send to the api info about, lets' say the record was created. So it should be added and sent or not added and not sent.
I think I can delete the last entry if the last (or second query) didn't work, but I think there is a danger to delete wrong entry. And it does not guarantee that this deletion will also work.
@Pavel There are never any guarantees in life! My suggestion would be to consider using an await function in a js query that triggers the additional steps - and/or reconsider your architecture - seems there are way to many dependencies for such a small amount of steps in what you have described.
Thank you, I'll try with js.
There are no dependencies at all btw, I just click a button that triggers add_entry query that triggers get_info query (on success) that triggers set_data_to_api query (on success). But despite on this "on success" thing they work randomly.
OK Yes, my point is that if you are chaining your queries/steps to proceed after each has succeeded, then that's fine, but you then if upon failure of step 3, you can run an event handler on Failure and delete the record added....
My suggestion would be to consider using an await function in a js query that triggers the additional steps - and/or reconsider your architecture - seems there are way to many dependencies for such a small amount of steps in what you have described.