That actually makes sense as well. I was initially worried about the creation of too many columns so i had gone with this method. Now, considering the efficiency of a Glide Big Table, it won’t really matter how many columns it has to hold.
As for the second problem i was facing, I am explaining it below with the help of screenshots and text.
In my app, there is a big table called the product activity master. This table is designed to keep of log of any modifications done to any product’s inventory. Each row will capture the product ID, warehouse where the product was added or removed from and the effective quantity.
Now, in my product master, which is a glide big table holding all my product details like images, product codes, prices and sizes, I am calculating each product’s inventory like this:
- First, for each product in my product master, I am relating the each row to the product activity master, allowing for multiple relations. Once I do this, i can essentially see a list of rows for each product that will show me everything that has happened to my product’s inventory.
2)Next, I am querying those relations to the product activity master with a query column, so that i can filter the rows from the product activity master for a specific warehouse.
- Finally, I am using a roll up column on that query column to sum up the total outstanding inventory value of that product.
The problem: Due to the way I have structured this, I cannot filter my products anywhere by their inventory.
A simple use case where I would require this would be:
- I want to see a list of products whose inventory value is below the set purchase order level. Example: Product A has 15 pieces in stock but the minimum quantity to maintain in stock is 50 pieces.
If i ever wanted to gather such a list of products, it would not be possible with this type of architecture.
The only way i could avoid this problem is by changing my inventory by incrementing numbers and having the inventory values as actual numbers existing in columns instead of just being calculated… This becomes very risky in a Glide Big Table because:
-
They do not auto-update unless the query is reloaded or the page is refrshed.
-
Glide does not have a way of avoiding the ‘race - condition’ that occurs when two users concurrently try to change a single value at the same exact time.
-
I also tested this out in a dummy app, where I tried to increment a number in a glide big table, about 1 second apart from two different devices: Glide just set the column values for that product of the latest response it received.
If user one incremented the stock of 100, by 5 and then user two incremented that same stock by 3, only one second after the first user, then glide just ended up showing the stock to me as 103, instead of 108. The +5 increment from the first user was lost.
@Darren_Murphy
