I am trying to refresh a repeating group populated by a mySQL query following a save action.
The save is working fine, rows are being committed to my DB fine.
The initial populating and displaying the repeating group is fine.
I cannot find a way to refresh the repeating group without a page refresh? I only want to refresh that group, can someone guide me in the right direction.
The downside of using the action of “Display list” is we’re redefining the data source each time.
Hi @emmanuel, could we get another action for repeating group elements (and other elements like Group and Text), of “refresh data”, to re-run it’s query where some of the results don’t automatically update? This would make a lot more sense.
I have actually decided to use the internal datastore of the time being due to the time it is taking to sort out some very simple things. I think this is great but needs a bit more dev work.
So far I have progressed quickly using the provided data store but its not what I would like long term.
Completely agree, I could really use this feature.
I have a very bizarre issue occurring after implementing this. I use a button labeled “Request item” inside a repeating group that initiates a workflow to hide library books a user has already put into his wish list (i.e. the workflow adds an book to the wish list and removes it from book available for sale/rental). Essentially, it adds a row into my SQL database, and then uses the “Display list” workflow action to refresh the repeating group and only display books that have not been added into the user’s wish list). The workflow works great the first time it is run, but only once. Subsequently, when I hit the button on another item listed in the repeating group…it doesn’t ‘refresh’ at all, although it does write the data into my SQL database (so it is executing the POST). No matter what item I hit from here on, the repeating group doesn’t refresh but the SQL database is in fact updated via POST every time. It’s almost like Bubble has a bug that doesn’t allow us to run the “display list” workflow action multiple times during a user session.
To test the bug, I logged out and then back in again (i.e. to see if the list would update)…sure enough, the repeating correctly refreshes to reflect the books that have not been added to the user’s wish list. The repeating group’s data source uses THE SAME CALL as I have in my “display list” workflow action. Any help, what is going on here?
Making an educated guess about the “reactive” nature … the data source is considered reactive, i.e. automatically updates, according to any dynamic data sources going into it, that it knows are dynamic. SQL queries results from an external system aren’t part of the internal chain of notifying when changed.
The first data source for the repeating group is as defined in the control, at the time of page load.
Then the workflow action overwrites the data source with a new definition (even if it looks the same query), so it does a refresh. From what I’ve seen the new definition is not as reactive as the first, i.e. doesn’t respond to changes in all of its source data.
Subsequent workflow actions attempt to overwrite the data source again, but with the same definition they’ve already overwritten it with, so from a reactive point of view, nothing has changed so a refresh is not needed.
Hopefully I’m wrong about all this, I’d love to know more about it.
@supernaturally can you try doing “display list” with a “search” data source instead of something’s value? Assuming it is a stored value …
A possible workaround would be to make the data source different each time, for example by having another condition on the workflow event that depends on some other value that is switchable, so in effect the button has two alternate workflows.
So I’ve been working on this for days, and have used a user_counter under User in Bubble’s database (adding +1 to the “user_counter” each time the query is made. Using custom states, this allows me to switch between two different workflows (use one workflow when “user_counter” is an even number, and use the other workflow when user_counter is an odd number)…each one making the query to my database service. Alas, it still does not refresh the data!
I have even tried to change the nature of the query based on different conditions (one query searches for all data, one query searches for data with a very minor condition [ex. only return data that is no older than one week]. Either way I do this, the data just won’t update. Maybe @emmanuel has a suggesiton: what else can we do here to refresh API-driven repeating groups after a workflow run?
Not a whole solution, but I found a workaround that refreshes on change of query parameter:
A repeating group with it’s data source being a query with several parameters. The parameters are defined as the first three items in a list of texts in a custom state. Then a workflow action to alter the list of texts, causes the query parameter to change, resulting in a refresh of the query and new data going to the repeating group.
[quote=“mishav, post:9, topic:7621”]
A repeating group with it’s data source being a query with several parameters. The parameters are defined as the first three items in a list of texts in a custom state. Then a workflow action to alter the list of texts, causes the query parameter to change, resulting in a refresh of the query and new data going to the repeating group.[/quote]
It looks like you’re using the DB Connector, whereas I am using the API Connector (my DB has an API). Even when I define parameters that are effectively changed during every call (because of the custom states), my repeating group will not refresh more than once.
I saw that @natedogg has a free ticker tutorial on codeless academy which repopulates info in a repeating group, but I’m not sure that his news is actually updated until the user logs out and back in again. Mirroring the same technique, I’ve also made it so that my repeating group makes the API call with constantly changing search parameters (I used the “until # Current User’s request_counter” so that the parameters of the call are always changing)
…still no luck. This issue has kind of hijacked this thread, so I’ve moved the discussion over to :