@david @Darren_Murphy
How awesome of you two to join the chat! (It’s an honor to have you David)
I made a wrong assumption. Let me give an example. (If you don’t have time, the conclusion is in fat at the bottom of this post but I think it’s harder to understand without the example)
Let’s say you have a project with two Big Tables:
1. A supplier Big Table → A supplier can have multiple Products
2. A Product Big Table → A product can be associated with one Supplier
I know that you can log calculated fields of big tables in simple text fields with the ‘Set Column’ action every time you create or update an item in a table. This is very useful as it still allows you to search, group and filter by a culculated field through that log field! I did this by logging the calculated 'Supplier Name" lookup column in the ‘Name Text Log’ Field in the Product table as you can see below.
The problem however with the above is that when the name of your Supplier changes, the Name Text Log field in the Product’s table will still show the old Name (while the Lookup field will change, which is irrelevant because we unfortunately cannot use to filter/sort/group) so filtering, sorting and grouping will happen on the old name.
My goal thus was to also change the ‘Name Text Log’ Column in the Products table, whenever the associated Supplier name was changed. I thought I could do this with an API call to the Products Table (with for every associated Product one mutation) whenever the Supplier’s name was edited. This would become expensive because if a Supplier has 300 associated products for example, you would pay $3 for one edit (You can buy edits for $10 for 1000 edits or $0,01 per edit).
To be able to create such an API Call and add it to an action, you would have to create a Template Column with the Body of the Api Call with for every associated Product one mutation. You can construct that mutation with a template column in the Product Table. I did this in the example with the ‘JSON Update Element’ see below:
However, to join the mutations into one JSON Array. You would have to create a Query Column in the Supplier Table which finds all associated Products. And then create a Joined List of the ‘JSON Update Element’ column of the associated Products.
However creating Joined Lists on calculated columns in Big Tables is not possible so you can’t possibly create an Api Call that changes a column value in all associated rows.
Therefore my remark becomse rather hypothetic and consists of two rather than 1 remarks:
1 - updating the Simple Fields in an associated rows in another Big Table (in order to use in filters/groupings/searches) when an entry in the current table changes in bulk is not possible. That’s a pity and changing that would be awesome.
2 - Secondly, if 1 would become possible. The current pricing of Glide wouldn’t work as 1 requires a massive amount of updates.
Finally, if 1 and 2 were to be changed. Big Tables would have almost the same functionality as Normal Tables (apart from the loading times of course) which would be massive in terms of app reusability. Instead of constantly copying my apps (with Templates), I would just be able to make every app with Big Table and onboard new customers on one and the same app. Meaning that any update I do in the app, I have to do only one time.
Finally 2: another and maybe even better solution to the above (maybe changing big tables is not possible) is that you would be able to create a ‘Master’ App and that copies from that Master App would always follow changes you make to the Master App. This way you could create SAAS like apps with Glide very easily. **
This would be an enormous increase in value proposition of Glide (more people would be able to onboard Glide apps → Agencies would earn more money → Glide would earn way more money). I will add this as a new feature request!