haha, I donāt really have an immediate need. Although I might⦠need to think about it a bit
The thing about Redis is that itās really easy to work with and it is blazingly fast.
Where Iāve used it in the past is to sit between a PostgreSQL database server and an Nginx webserver. Instead of the webserver continually hitting the database server, it just reads from the Redis cache, which is updated periodically. Got great results with this setup
**[quote=āDarren_Murphy, post:21, topic:67979ā]
a PostgreSQL database server and an Nginx webserver. Instead of the webserver continually hitting the database server, it just reads from the Redis cache, which is updated periodically
[/quote]
**āno codeā they said
Hi i put up a post recently about the speed of the API and you had suggested using an aggregator to pull all of the API calls together and make a single call that updates all rows at the same time.
In this context, and your reply on this thread, are you stating that the new Make.com module wouldnt be able to update multiple rows in Glide at the same time?
I note that it has only add row or edit row, but that it has a pluralised get rows.
Following from this question, is it likely that because the new module is native and not a generic http module, that adding multiple rows, for example, through this method instead of a generic http module would be quicker, or is that a technically difficult question to respond to?
Not on its own, no. Youād need to combine it with an iterator and call it once for every row to be updated.
I would say no, simply because with a HTTP module you can make several adds/edits/deletes (up to 500) with a single call. I would expect this to be much faster that using the Glide module, especially for larger numbers of changes. Itās also going to be cheaper in terms of Make operations. Eg. One operation vs five hundred operations.
I wouldnāt say itās ānativeā. All it really does is abstract away some of the configuration. So if all you need to do is add or edit a single row, then itās going to be easier to setup and use. But for large numbers of mutations (changes), then using a HTTP module is a superior option.
Do you happen to have a screenshot of how you set up the aggregator with the JSON module and HTTP module to achieve this? Ive tried to do it but havent been successful
Hereās what I did for one of my scenarios.
Iterate through the list of IDs I send through the webhook.
Text aggregator to create mutations.
HTTP module to do a batch API call.
This was a long time ago, I would have used an aggregate to JSON module to make sure the JSON is correct.
Start writing custom API calls and youāre squarely in the ālow codeā category.
Thereās always been an element of low code in Glide, though, what with the Experimental Code column and all.
Hello! We are really excited to start using the Make integration to add/edit rows in Glide, however, cannot find those modules in make, are we missing something? I can access the Glide trigger, but not the module I see in the example to create or edit rows. Any guidance would be appreciated!
You need to accept the invitation (click the link) that David provided in his initial post.
ahhh, thank you!
And sorry, one more question, Iām struggling as to where I can find the API Key in glide to setup the connection. I donāt see Make as an integration option in integrations, and not sure where else to look.
Thanks!
Go to the Data Editor, right click on a table name, and choose āShow APIā.
Youāll find the bearer token there.
Itās great to have this. Although my experience of it actually writing to the database is the same as when I used the HTTP module, randomly none of the data reaches the database (and on occasion only partial data), when the make module receives a code 200 response, or āEdited Row IDsā response.
Any Airtable imported tables are not available in make.com
It would be great to allow us to update records in these tables even if the source is Airtable as it would be a lot faster than waiting for the Airtable update to sync.
Not sure if im doing something wrong with the āGet Tableā action, but when i use it and run the module, it only comes up with the column types, but not any data in the columns.
The set up screen also only asked me for the table, but not the rows (which is what i was expecting). Am i doing something wrong, or does this action not provide actual table data?
Iāve built a couple scheduling solutions for clients ā atomic actions would be amazing!
100%, atomic actions would be so awesome.
Time to create feature request for atomic actions!
So iāve been using the make.com glide integration for a while now, getting tables, adding rows, and editing rows. With some creativity on how you filter the rows to edit, it seems to work very well. I am calling it all day every day for my app to communicate with other software and end points, without this Glide would not be useful to me, thank you and please continue to devlop out the new features that it can have! It has even enabled me to have a chat, conversational based component inside my app for SMS, using text magic as my sender/receiver. I would say my glide API usage is about 5X higher than my actual app updates usage just due to the different software I am combining together into glide.
its been amazing, the glide app runs my business!
One thing I would like to see is a āsearch rowsā function. So that you can search the row(s) based on criteria and edit those rows.
Also would like to see the column names instead of the unique id that each column is given. In order to get around this I go to the glide table in the data editor, view API, copy code, paste into notepad, search my actual column, get the unique ID then make changes in make.com. I start to memorize the column names after a while, but some of my glide tables have 230+ columns dang it, I cannot remember all of that.
I would agree with this. If Glide can somehow sync the column name from the app to Make and display it on the front end then it would be superb.
I think itās related to the fact that for a long time, Glide wants to protect the calls from failing if you ever change your column name. Hence the POST call has to reference the underlying ID.