In one of the apps we are building we are potentially looking to add 1000+ items to a list in a relatively short timespan (same day). Meaning that there is a chance of “Add to list” operations happening at the same time.
Does anyone know how the backend logic of this Add to list operation is, and if there is a chance of race conditions where two simultanious operations only will result in one item being added?
If the underlying logic is that bubble retrieves the existing list, adds the new item, and then update the list value with the combined result than this can happen (and I’d need to look at an alternative implementation)
@NigelG , thanks for pitching in.
I mainly use recursive workflows for list changes, but this one is triggered by different occurances. Each one comes from a unique user creating a booking, and that booking then being added to a list on the assigned service provider. I can’t immediately see a way to make this recursive, can you?
I think you should rely on one-to-many relationship instead of list attribute. Bublers don’t like it and there are some cases when this architecture overhelms logic, but from a few details you’ve mentioned I see this could be a solution.
Another option is to put bookings into a temporary table and then process then in the backend and add to list batch by batch, if you don’t need that list to be actualized in the realtime.
@vladimir.pak, thanks! Meaning to add a single-value field “Service Provider” on each booking and doing a search for all bookings for that service provider when I need to access the data? If so, I have that as well (used in various workflows), but my main reasons for wanting a list is the load time when I load a repeating group to display the bookings for a given service provider. My thinking was that it would be slower to do this search than to load a list.
Yeap, exactly.
You may try the following trick, though it’s not the best practice and I don’t know if RG won’t flicker in your case: initially set RG datasource to list field (optionally making it static), and add condition to compare this list againts lookup query result. If they don’t match, change datasource to lookup query. Another option is to query an update of the list field in the background via API or some other way once client finds that list differs from query result.
Anyway, you cannot rely on list consistency, the question is whether temporary inconsistent list is acceptable at the client side…
How about having the data source be a merge between the list, and a search, and then extract the unique elements? It would be a mix of fast load time for most items, and then a fail-safe for those not on the list. Do you know if there :Unique Elements funciton comes at a performance cost?
Don’t know if merge locks until lookup completes. If it doesn’t then yes, that’s better solution.
The :unique elements performed at client side is fast enough not to worry about, and your list must be rather long for it to become a problem, but long lists are 1) discouraged, b) limited to 20k items. Anyway, you don’t need “:unique elements” after “:merge”.
It turned out that bubble debugger was very angry about the idea of conditional data source saying that it’s unstable and I should remove this condition. Just noticed a message about that in my test environment.
and there are some cases when this architecture overhelms logic, but from a few details you’ve mentioned I see this could be a solution.