Update: We’re aware of some users experiencing issues with Glide + Make.
Our engineerings are working on it.
If you’re encountering any issues, please add them to this thread.
Thank you! 
Otherwise: We’re working on an improved Make integration for working with data in Glide Tables.
Awesome! Thanks David!
Hi @david , this is great!
Even if it is less known, the Make & Zappier competitor “n8n” is also an interesting candidate since it can be used for free when setup locally (cf. opensource).
Best
This is looking really good, much easier than using the HTTP module. Nice work!
Just reiterating my comments made on Slack:
Query Tables module, something that would make it easier to construct SQL type queries for Big Tables. A WYSIWYG Query builder would be the nirvana, but even something that allowed us to work with human readable column/table names would be a great start.What will make do if to users try to edit the same row’s same column at the same time? For example at the same second, two users modify a product’s price to $100 and the other user at $120.
As per my understanding, make will run these scenarios concurrently and not sequentially, correct?
So what method would you suggest to enable sequential processing of data?
Add rows with changes, rather than actually editing a row, then you can decide what to do in your app.
Okay, that does make sense for something like product price updations that don’t need to previous price to set the new price.
Yet, when it comes to a product inventory update, the sequential processing needs to occur such that each inventory modification request is processed before the one.
This way, the old stock + the new modification will result in the final stock.
To ensure this happens, I have pushed my inventory modification requests to Google sheets where each row is processed sequentially. Here, the row is processed by calling the glide api, getting the previous inventory and then setting the new inventory value.
All this to avoid race conditions.
Instead of us trying to use make to process data outside of glide, would it not make sense that have basic locking mechanisms in glide’s native sources?
Great!
Some little scratches
Add row module not displayed real Column names if names are created after adding the module, run once didn’t solves this.
But the Edit Row module correctly showing column names.
And the Get row module not read empty column
Glide’s native sources do have locking. I am not sure how you imagine it could work differently. If two users make the same mutation at the exact same nanosecond, they would still get queued and the last mutation would ‘win’.
You want to see the display names instead of internal names when you Get Rows?
yes
Or both?
Okay, from what I am understanding, you are saying that if two users are trying to increment the column value for product A in its total inventory column and user 1 is incrementing it by 100 and user 2 is incrementing it by 200, then glide would queue these up, even if they requests were made at the same nanosecond, and in that queue, the last request would be processed and the requests before that would not be processed.
I have spent quite a few hours trying to figure out if glide can sequentially process data using this testing app: Testing Grounds 1. You can try it too.
I have tried to see if glide can process many requests to increment number sequentially on glide big tables and normal tables.
What I have found out is that if 2 more more user’s try to increment the value of the same row at the same time, only one requests of the many requests will be processed.
In the case of inventory management, if two users increment the same product’s inventory at the same location at the same time, Glide should be able to take the first request, increment inventory, and then based on the new inventory value, the second increment inventory request should be processed.
In summation:
Initial product A inventory at warehouse 1 = 0.00
If user 1 and user 2 try to increment product A’s inventory at warehouse 1 by 100 and 200 respectively at 10:01:59 pm, then Glide should be able to do the following:
Product A inventory is incremented from 0 → 100 by user 1
then
Product A inventory is incremented from 100 → 300 by user 2
I have tried and tested to check if Glide can do this and I have realised it cannot.
My request to the Glide team: Please make it possible that the data sources can behave as described in the scenario provided above.
For GlideApps being one of the best no-code tools in the world, I have had to do a lot of scripting and work outside of GlideApps just to get my inventory to be processed sequentially.
P.S You can play with this app to test how Glide processes simultaneous requests: Testing Grounds 1
Increment is not an atomic operation. The increment happens on the client, and the result is sent to the server. For atomic increment, you should use Call API with a service like Upstash that offers serverless redis (a database with first-class support for atomic increment). You can get a good result this way! We did it for PGA when they needed a distributed counter for their grandstands.
We’d like to offer atomic increment in Glide but it’s not a top request from customers yet.
Awesome, thank you for the suggestion!
I’ll check it out!
oooh, Redis is freaking awesome. I’ve used that extensively in a previous life as a front end database cache with Nginx. Never even occurred to me that it could be used in this way with Glide…
Yes, Upstsah especially has redis with a REST API that plays nicely with Call API.
Now that your wheels are turning, would love to see what you come up with here.
