@Kent, I can’t vouch 100% on the database side for what Bubble does on the backend when asked for
Search for Things :count. But I do know the Bubble plugin API very well and we know some things about how this all works in that scenario.
First, I do this in some of my test apps and it’s true that even with a very large database of some Thing (like more than 150,000 Things of a given type),
Search for Things :count in a text element, for example, returns nearly immediately and doesn’t actually cause the values of the
Search for Things part to be fetched.
length(), which allows us to inspect how many items are in the List (this function returns what you know as the
:count, in Bubble terms).
So, as you can see, we can actually know the length of a List without unpacking any of its items. It’s actually this process of unpacking the items with
get() that, in the case of a list of Things, causes the Thing objects to be fetched from the database. And this is the “slow” part of fetching a List.
I take advantage of this in List Shifter, BTW. Well before any items are fetched, I publish the result of List.length() to a numeric exposed state that tells you the number of items in the List (it’s called Num Items or Number of Items or something like that). This is sort of invisible because I don’t trigger the initialized/updated event until everything has been done, but this Number of Items state gets published pretty much instantly and well before the items themselves are published to outputs like Original List and Shifted List.
Search for Things :count works in the same way in a Bubble page as it does in a plugin, I guess one of two things could be going on with respect to WUs: Either the search operation itself (not the count part) essentially “gathers up” all the items, sending us info on how to eventually get() them and this gets counted as “that many things could be returned by the search” (even though in this case we never actually get them), and this might be a miscalculation on Bubble’s part.
It’s probably only in the somewhat weird plugin case where we might ever exploit this, in the way I describe with List Shifter. When it unpacks the List, if the List is full of Things we actually don’t fetch any of the values in the fields – not even its unique ID – we just leave the Thing objects as they are and publish them to the Original and Shifted List states. So any further data fetching only happens when you eventually reference those fields somewhere else.
I can’t be sure about how all of this truly works with respect to the db. (Like, if a List is a List of numbers, do the numbers themselves come along as part of the List object? Or are the values only retrieved from the database when we actually execute .get() on the List? I have no way of knowing because the only way to “see” the constituent items in the List is to use .get(). I suppose I could inspect the Network activity but that wouldn’t 100% answer the question.
Anyway tl;dr: The count/length of a List can be determined without looking “inside” the List and, this action is pretty much instantaneous, and if you never unpack/get the List, is it incorrect to charge you for that?
Note that I have not inspected this sort of thing with respect to WUs yet, but I guess that’s another very nichey-niche thing that I need to understand now. No point in looking at this further until we see the new WU consumption in our apps tomorrow or whenever that gets released.