Counting with trigger on data change

I’m trying to adapt @romanmg 's chat system using trigger custom event when data changes

But my thing isn’t as complicated as what Gaby did, it’s just supposed to count down to zero. It’s supposed to keep calling the “subtract 1” operation on itself every time the previous workflow changes the number, but it only the first flag works. It stops after the first iteration.

here’s the editor

and here’s the page

Check out the test page I added to your sample app. The active workflows are in Green. In general, not sure how accurate this is going to be - it “works” but looks like some numbers get skipped or it hangs on them. Try it out.

Awesome! Thanks, this trick is easy to get wrong.

So it looks like this is the format you used that worked:

  • count_start (date)
  • count_end (date)
  • count_count (number)

[begin count]
change user: start & count - trigger [1] on count change - trigger [user-update]

change user: count & end

trigger [2] on count change - trigger [user-update]

trigger [1] on count change - trigger [user-update]

For comparison, I had tried to do this in the first workflow
[begin count]
trigger [1] when count changes - change user: count & start

So it looks like the difference is that you only used [user-update] to cause the data change that activated the flags. I tried to use the initial empty->count action to both initialize the count and trigger the first cycle. You also used “current workflow user” for a couple of the flags where I used “current user”.

When I rearranged my [begin] workflow to look like yours, my page still only does one count and then stops.

When I change the trigger flags to use “current workflow user” my page counts without stopping.

When I try setting my [begin] workflow back to what it originally was, the page doesn’t even count once.

When I change it back to the way you did it the page counts correctly again.

I changed loop 1’s flag action back to using “current user” instead of “current workflow user” and the page returns to only counting one time then stopping.

So it seems to be sensitive to at least two conditions:

  1. the action that modifies the data and triggers the flag should be in a different workflow from the workflow that set the flag(?)
  2. if available, the flag should use “current workflow user” instead of “current user”
1 Like

For #1 - I think this might be due to a timing thing . Possibly.

For #2 - Yeah, the flag attaches itself to the Thing defined in the custom event. So, the fact that you’re using Current User confuses the mind a bit, but pretend that this is a different Custom Thing. Initially, you need to send something to the custom event (in your case, the current user, which is fine to use when the loop begins). From then on, it needs to reference the Current Workflow Thing (user) because that’s the thing being passed around.

Yeah, that makes sense now, especially since they’re listed separately as “current user” and “current workflow user”. They must be different records in Bubble’s backend, even if they refer to the same thing eventually.

After letting the countdown finish, it looks like the loop is processing about 30 items per minute. That’s still faster than the schedule API workflow option which can’t do more than 12 per minute. Still frustrating.

Since both pages are editing the same field(s), I tried running both pages in their own tab. That sped things up; it managed about 40 items per minute.

If I open one page in three tabs and start the process in all three of them it goes faster, 50 items per minute.

It seems reasonable that all of these flags are going into the same queue and there will be a limit on how fast they can run. It might be possible to get them to run in parallel by having different tabs with different logged in users, which will use different sessions, and might be able to command more server resources. However, that would be almost guaranteed to cause errors, and would be tedious even if it didn’t cause errors, and it would have to achieve at least an order of magnitude increase in items/min to be worth setting up. It seems unlikely to work well enough to speed things up that much, but if someone else wants to try it there’s still the possibility.

For comparison, when I use the GET API to export data via JSON to another server it moves about 900 database records per minute, and when I use mySQL to process the copied database it churns through 100,000 records in a second.

I’m curious how fast Bubble can run analysis and reporting on a dedicated hosting plan.

This topic was automatically closed after 70 days. New replies are no longer allowed.