When are client-side loops (via SimpleLooper or ListShifter) unreliable? I seem to recall that hitting the DB with them is a mistake, as things can time out. Inherited an app that’s creating a bunch of things during a registration flow with some quirky & inconsistent buggy behavior. Trying to figure out the merits of rebuilding these rather complex WFs as BEWFs.
Also wondering this generically speaking, but this specific issue is happening in SimpleLooper by the awesome @vini_brito
As I’ve noted time and time again over in the List Shifter thread, and as I warned in the intro video to List Shifter’s iterate feature, this is not a recommended use case and there is no free lunch with database operations. I won’t belabor this further here.
2 Likes
Hey Keith, thanks much for the reply. Funny, I was referring to that master thread when I said “I seem to recall”. But since the app I inherited uses SimpleLooper, wasn’t sure if the same story applies, and obviously it does. What’s still leaving me scratching my head is the behavior is seen even in relatively small lists of ~4-8 items. Do you know if there’s a console/bubble debugger/log that’s a telltale sign that the client-side looping and creating DB objects is the culprit?
So, @akalati, I assume what you are probably doing is leaving the page before the items are created/updated in the database. (And unfortunately, there is no convenient way for us to know when this has happened.) It’s also very easy to cap out your app (exceed momentarily available capacity) in this way.
Note that, when testing stuff like this you may be exceeding your capacity because, well, you’re testing and just firing these database operations constantly over some short period.
Anyway, let’s say you’re doing a shopping cart thing and when you click a button to go to the checkout page you’re iterating over a list of selected products (perhaps to create the line items for the order), so you fire Begin Iterate, and on End Iterate you’re like, OK cool, done, navigate the User to the checkout page.
Well, what has happened is that, while the Things appear to the page that they exist (the Things exist in their Bubble object form in the page) some or all of them do not yet exist in the database and will not be available to the next page (the page to which you navigated). They are not searchable as they do not exist.
In computer time terms, End Iterate happens waaaay before the objects are created in the db, even if you have lots of capacity. All your iterative workflow does is queues up these pending database operations. If you leave the page before they are done (again, there is no programmatic way I am aware of to establish this) any pending database actions simply disappear/get cancelled.
If you test this the right way you’ll observe that, at times, seemingly at random, a db creation or change will take substantially longer than usual so it’s simply not safe or capacity efficient to attempt to do things this way.
I’ve discussed this in various places at length, but @tylerboodman asked me about a related topic and you’ll probably find my response to them helpful:
2 Likes
BTW, I do have some ideas about how this might be accomplished, but I think Bubble will fool us every time. Not sure if I’m in the mood to test that ATM.
Got it. Thanks much for your very detailed explanation Keith!
@akalati and I did play with this a bit yesterday and still find everything I said above true. I have a little demo page where there’s a button that - when clicked - will create a new Order and then generate a dozen Line Items items and attach them to that order (via a List Shifter iterative workflow).
As expected, in the page, the objects are created immediately vis-a-vis the page. But you can, in a separate window look at the Data tab for the app and see that it takes some time for the objects to show up in the database.
Further (this is a demo app running on a personal plan) spamming the button about a dozen times will bring the app to its knees due to capacity overrun. And in that case you’ll see many objects either fail to create or become (deleted item).
1 Like
I already trusted everything you said but appreciate the extra testing/validation. Thank you!
1 Like
This topic was automatically closed after 70 days. New replies are no longer allowed.