You simply repeat the field and do “+ 1. Repeating the field means it will take the value of the field and since it is a number type field you can add any increment to it
When you want to know how many users are age 18-25, all you actually need to do is Do a search for users:count with constraints for Age >= 18 and Age <25.
That will always return the correct number of users between 18 and 25. You can place this expression anywhere on your Bubble app, including on the page using a text element if you want to see it.
I was under the impression that it does matter how many records there are but perhaps I have misunderstood the manual on this part:
Starting the aggregation calculation has a cost of 0.2, but the data to be aggregated needs to come from a data source. In many cases, this will be the result of a dynamic expression using the Do a search for data source.
What this means, is that this operation needs to be added to the total calculation. According to the activity type chart, a database search has a starting cost of 0.3. The complexity of that search can add to the cost of it.
Given the fact that you help people with optimizing for WU I am inclined to take your word on it. Do you know why there are no increasing costs for a do a search for when there are many rows to search for?
Do a search for Things returns Things (0.3WU plus Things returned) , Do a search for:count is an aggregate query. Only 0.2 WU is charged (and it’s therefore cheaper than a standard search).
Because Bubble doesn’t charge for it, but the reason they don’t charge for it is likely because the database volume doesn’t substantially impact the resources it takes to run an aggregate query.
Thanks for the information. As I have no other information than that it does cost about the same resources to run an aggregate function in postgres as it cost to run the function itself, I thought bubble would price it as such. But it could be the case that as of this moment the aggregate queries costs are less. I am not a postgres expert ;).
It’s just bad practice to build conflicting information into your database. If you have a table of users whose properties are fixed, you shouldn’t have a separate table which is derived from those properties because then you are creating an obligation on yourself to keep those two facts consistent, when this is literally the point of the database.
It would be like checking out a book at the library, and then having to fill out a form saying what book you checked out- like, they already know what book it was because you checked it out.