No, not really. But concurrency can definitely be a problem, and I’ve bumped into its effects several times.
My goto solution these days for dealing with race conditions/concurrency is to delegate to Integromat. By funnelling critical updates through Integromat I’m able to ensure that they are queued and handled serially, and avoid users tripping over each other or clobbering each other’s updates.
Below is some more reading on this topic, where I described an option for a specific use case:
No, it’s not. As far as I’m aware, the only way to ensure immunity is to delegate updates to a 3rd party.
Thanks again.
Integromat, or any 3rd party call, will again create these lags when you have multiple concurrent requests for such a “protected counter”.
No way of doing it inside Glide without risk of concurrency?
As this number is used rather often (for each new lead), it’ll most definitely happen concurrently. Integromat will accept the trigger, but surely delay its response, thus creating a lag.
I guess it depends on your use case, and how quickly you need the result. My most recent use case is as follows:
Twice a day, I have about 200 users that the submit a result of a “test”
They all do it within about a 1-2 hour timespan
As each user submits, their UserID is added to a list of users that have submitted
The end result is a single joined list of ~200 user IDs.
When I first implemented this, it was all done within Glide. Each users ID was added to the list as they submitted and a new list was written, replacing the existing list. On the very first day, I had several users complaining that they had submitted, but their name didn’t appear on the list. It didn’t take me long to figure out what was happening. Concurrency. If 2 users happened to submit at the same time, then the last one in would win, and the first users ID would get bumped from the list. The answer was Integromat, and I changed my flow as follows:
Now as each user submits, a webhook is sent with their UserID and the TestID
Integromat checks the backend sheet to find the correct TestID row, and adds their ID to the list.
If two or more users submit at the same time, it doesn’t matter as the requests are queued.
Since I’ve implemented the above, it’s worked perfectly and there have been zero complaints. So again, it depends on your use case. If you need instant results, then no it’s not a good solution. But if you can live with a slight delay, then I think it’s the most reliable solution available at the moment.
Thanks!
I’ve found a nice little API which might help, but I’m again concerned about concurrency and speed.
The API is name Newton.
For our super-simple use of incrementing a number:
1.
https://newton.now.sh/api/v2/simplify/LN%2B1
PS - This URL is created with a template column within Glide as the Construct URL column seems like an overkill.
Using the API column to reach the API
The result is fine
Now I’m at a roadblock as to the best way to extract the number after “result”.
First, what do you think about this solution?
Second, any suggestion as to how to extract the result?
PS - I’m finding it super hard to believe that we need 3rd parties just to avoid concurrency for such a simple task. This should be handled within Glide.
you’re good!
Documentation isn’t Glide’s strong suit. So many great features but no explanation as to how to use them. Good thing we have this wonderful community.
While I have you, any ideas on how to increment a number within glide, avoiding concurrency for a mission-critical counter?
I just noticed something, but I might be wrong.
Is the API column calculated every time the sheet is updated?
If so, it’s VERY bad for a fixed number (such as client number).
Even if we “set value” using an component action, we’re still (again) at risk of having the two or more concurrent actions happening together
Are we really forced into LockService on Google Apps Script?
HI
Could you please share some more information about how this is done?
I seem to be struggling with the “parent” table instead of a single-row table as you suggest (which I already created, as a Glide Table and not Gsheet).
Perhaps possible to apply an example here?
What you mean is that instead of adding a New Row to animals, you’ll start a new screen point to this single-row table. But, then what? Every other action will still point back to the animals table.
hmm, I need to update that app. I wouldn’t do that action like that now. The else there is completely un-necessary, and I probably wouldn’t have that extra Set Columns action in there.
It’s late here, but try to find some time to have a look tomorrow.
Thanks @Darren_Murphy. Another issue that I’ve noticed (or shall I say another thing I’m doing wrong): When we use the “Show new screen” action it works only once per each app screen. If we put another button, asking for a new screen from it, we’ll get a generic Glide details page. Surely I’m doing something wrong, which is why you guys save me each time
Edit:
My bad about the single screen issue. I simply configured the action wrong. I forgot that each new screen has to point to “this item”, which allows us to manipulate as needed. It seems like a rather strange, not to say aggressive, workaround in the sense that we need to demolish some/all connection to “this item” in order to have the freedom to create our customs forms.
I like the concept of your template to check for duplicates. But I was able to EDIT and change Tigers to Tiger, and it didn’t catch the DUPE, then. Personally, I would not allow edit on a field that had to be NO DUPES ALLOWED and we had already checked it for that.
I’m also not following what all the empty entries in the database are for. Are they all simply temporary edit rows that got left behind? I’m impressed at the work that went into this template app.
I appreciate the implementation of calculated string columns (lower, trim, etc).
I think to fully understand all the concepts I will have to create my own template.
Preventing duplicates from being created on edit is a little tricky, but it can be done. Essentially you need to create a relation that excludes the row being edited. This is something I had to do recently. If it is something you need to do, let me know and I can provide some more details about how to approach it.
Thanks, I’m sure someone might. But I’ve been using NO DUPE indexes on data for so long, I’m used to columns that cannot be changed once created, and I’ve very rarely seen circumstances where they had to be (in those cases we’d do a delete/insert)
Thanks, the updated APP works like a charm, as well as one other feature that was broken in the copy I downloaded seems to have been fixed (the “animal name taken” was not showing – it simply would not highlight the ‘save’ button).
I love the working table concept, also. This does lead me to the question, you had specified the user-specific columns with using “USC / Column Name”. I don’t seem to be able to find any documentation describing that. I always implemented user-specific columns with the check-box.
I had prior noticed a column I had named “Notes / Memories” had been implemented in a strange way, but I don’t think it was truly “user specific” because if one user changed the column, everyone else saw the changes.
