Hello,
I have an objet A, which hold a list of stuff B.
I am calling an API workflow that deletes B, and then I want to delete A.
Questions :
when I schedule the API workflow on a list, does it somehow copy in a temporary variable the list or does it get all messed up if I delete the list in parallel ?
how to delete A after all B are deleted?
Best
You could schedule it to run in a long time like an hour from now, and hide it from the user using a field deleted = yes.
Alternatively, and better, add a āDelete Aā only when Aās List of Answers:count is 1 to your delete answer workflow (this will delete B only when the current workflow is the last answer).
Thanks,
Iād like to add that kind of condition in the ādelete Bā workflow, but I am not sure. Is each API workflow scheduled from the initial list aware of its surroundings and how many other workflows are scheduled ?
Do all these run as a list or parallel ?
In parallel, at a rate of about 50 per second if
youāre on the WU plan depending how long each workflow takes.
If they run in parallel at a high speed, then it seems to me that relying on a count may be risky.
Letās say I throw a batch of 50 workflow in the wild, and in each of those I ask them to do a search and count things. While at the same time they are being deleted.
What am I missing?
You could encounter race conditions. If itās not urgent, just schedule them with a 1s interval.
Why not just Delete a list of Things?
If you need to do other things when a Thing is deleted, move anything thatās in the API workflow to a DB trigger that runs when Thing now is empty (this condition is only true when the Thing is deleted) and do it in there. DB triggers are so underused by most bubble devs.
Add a parameter to the backend workflow. Call it last item unique id. When you schedule the workflow on the list populate that parameter with the unique of the last item in the list you are running the backend workflow on. In your backend workflow use a condition on any action you want to trigger at the end using the last item unique ID parameter is āthis items unique idā.
I need to do some API calls for each item deleted, so I really need to do that 1 by 1.
Yeah good idea for the DB trigger. That might be a good solution, altho I need to double check with some user flows as some scenarios may result in deleting some B without the intention to delete A.
How about:
Smart one, thanks!
However I feel terrible, but as I am making API calls in each workflow I canāt really rely on the fact that the last item from the list will reliably match with the last workflow being executed (and finished)
Yeah the more I think about a DB trigger the more I think itās the way to go.
I believe Iāll add a boolean field to my āApplicationā datatype āIs scheduled for deletionā, and check that field in my DB trigger.
So when a DB trigger fires on a B deletion from an A, it checks if A Is scheduled for deletion:yes, and if yes then boom ciao byebye A
Yes, this is generally a good way of doing it. isDeleted (yes/no) is my go to. Then, if you configure privacy rules right, itāll look deleted to the user even if it still exists in the DB for a bit while you do stuff before actually removing it.
Not a fact. Just a gut feeling. But yeah, if you feel like it wonāt work for you, it might not work for you. But in an app, it is reliable and works properly to do what is needed, which is to run actions only after the last item in the list has been processed.
