Referencing repeating groups list of things creates new search?

Questions
1

Hey Bubble team,

I need some clarification here. We have a conditional that references a repeating groups list of things and it’s accounting for a huge amount of WU.

My assumption is that a repeating group's list of things would be a value that is already available in the browser. I would for sure expect that repeating group's list of things: first item is empty would be a readily available boolean value not requiring a db call to fetch.

However, as you can see from the chart, this simple conditional is using up more than 3x the number of WU the actual search on the repeating group (in dark blue) is using.

My question ultimately here is, does referencing a repeating groups list of things create a new search or nah? If it does,

  • Does it create a new search every time or just sometimes?
  • If just sometimes, how is this determined? What are the paramters by which this is determined?

Additionally, when can we get an is empty value on lists?

image

1 Like
2

Hey Eli!

I assume your using a search as the RG’s data source. Of so using RG list :first item is going to make calls to the database more than you think.

Check out this thread by @adamhholmes

2 Likes
3

Hey! Thanks for the response. That is a great thread! However, I’m still at a loss as to why a repeatings groups list of things would trigger a search. Surely the repeating groups list of things is a cached value that’s already available from when the repeating groups search was done?

4

I guess it’s just the way Bubble handle’s Searches as data sources. I had to drastically reduce the number of data sources using Searches in my app as they incurred A LOT of WU.

1 Like
5

@eli I haven’t looked at any data in this regard, but could the answer be that the RG only loads what’s needed for the visible data in the RG, while referencing it forces Bubble to perform the full search?

If so, maybe it’d help to turn it around and load the full list somewhere and then set the RG’s data source to that search.

Just thinking out loud now…

2 Likes
6

That’s a possibility @petter. I hope not though because if we can’t reference the count of an RG that will require managing a lot more searches in an app.

I’ve made some changes to test mitigation options so we’ll see what happens over the next couple days

1 Like
7

One thing I’ve observed on this is the following:

Loading a list into a RG performs both a search (returning the data) AND an aggregate search (returning the count) regardless of whether or not you reference the count.

Whereas loading the same list into a custom state only performs a search (no aggregate search) so ALWAYS costs 0.2 WU less that loading the list into an RG (aside from any additional real-time data costs).

Even if you then refer to the custom state list count - no aggregate search is performed.

So, the cheapest way to display a list AND display the count of that list is to load the list into a custom state, set the RG data source to that custom state list, then refer to the count of either the RG or the custom state list.

That seems to always cost 0.2 WU (the cost of an aggregate search) less than setting the RG datasource to the search.

I’ve got no idea why that is the case - it’s simply an observation of what happens. Probably another bug in the way data is retrieved that has never come to light prior to WUs.

Another thing I’ve also observed:

when referring to 1 RG list in another RG …

If the list is relatively small (a few hundred items) only a single search is performed.

But with larger lists (a few thousand things) it seems as if the second RG (which is referencing the first RG’s list) starts to do its own search for the same things as the first RG (presumably because the first RG’s list isn’t there yet to reference)…

Which results in the entire set of data being loaded to the page twice, and being charged in WUs twice for the search and data retrieval.

Putting some conditions, to force the first RG to load all the data before the second RG makes any reference to it seems to mitigate that issue, and half the WU cost (although if course it’s slower).

3 Likes