I would like to be able to easily create a lock (actually multiple locks) on a per row basis and I want it to guarantee the lock. Currently I am not sure if one user writes to a cell and another user reads it there is guaranteed order of execution so I am pretty sure a lock can not really be implemented perfectly. Pretty sure this is not the case given the delays I see in data showing up between updates of cells. In addition if the app terminates, the user quits the app, I need the lock expire. The lock should be as easy as creating a lock column in the glide sheet and then writing to it would give me a lock, I would like to be able to have multiple lock columns. Preferably I do not want this to go to the google sheet. I want this to work for a public app, that is, no email login.
Whatās the purpose of the lock?
My application is a reservation system for sporting equipment use on a lake. We have in each time slot a limited number of spots available. Once someone starts reserving I need to lock out all others from trying to reserve the same spot so the spot is not double booked. Once the reservation is finished being made the lock will be released.
Of course there are the consequences of the reservation not being completed.
I guess you could look at it as the same problem of booking seats at an event.
In my opinion it should work like this: First prepare a key to save in a userspecific column using, for example, a welcome button. When the user selects the slot to reserve it, you will save that key in the slot if there is not already an unexpired key. When you save it, also note the date and time of saving. Add an ITE column that checks if the key has expired based on the maximum time you have decided to fill in the registration form.
Sure that may work but there is a delay (at least 3 seconds) in updates being pushed out to all the running apps. So if the app for user A checks the key location it could actually be locked by say the app of user B (for up to the delay time) but not show up locked in the user app A. In order for it to truly be a proper locking mechanism all the checking has to be done at the glide server and status of the lock needs to be returned to each app. Hence the request to implement this as a feature.
Basically requests on a lock column would have to go to the server not just look at local copy of data in the app.
Yes, I already understood. The fact is that Glide is not a typical client server application. The database is on the device and it is synchronized with the db on the server periodically. So you should find a way to handle this delay. If I can advise you, if you have this wall in front of you, look for a way to get around it rather than blasting it. Iām sure you will make it. Ciao!
I have this issue in my telemedicine app, and the way Iāve addressed it (after many tries and fails) is:
- use an external source (of truth)
- send a webhook to integromat
- integromat does things (including a gmt Timestamp that is not based on the user device
- and sends the result to GS in some way (could be add row or update row)
- in GS, run scripts that ādo thingsā
- then lalala data eventually gets pushed back to Glide, then user devices
So I am a little bit offended by this comment about āthe wall in front of meā¦ā. You do not even know what I have tried to do try and work around the problem. I am sure that you did not mean it to make me feel offended. As a user of Glide for a couple of years now, and after programming mission critical systems for 30 years, I have found my way around lots of problems/walls. All I was asking for is a method to lock not blasting down anything. Now that I have that off my chestā¦
I still think Glide needs to find a method to do a lock, every mission critical system (or any system that has a constrained resource) would require it. Now maybe it is not the intention of Glide to be used in mission critical systems, fine then just tell me this feature request will never be done. Right now what is happening is anyone needing a lock is implementing some method to work around the lack of locks in Glide, if Glide was to implement it would overall mean less work for everyone.
Now it turns out the application I am implementing can probably live without it so I will continue using glide for it, but without locks I doubt I would even consider it for a more critical system or any system that has a constrained resource.
Thanks. As noted else I think I will just live with the double booking issue if it crops up.
I am very sorry, it was absolutely not my intention to offend you. On the contrary, I was hoping to be able to help you out, and thatās always my spirit with anyone in here. I donāt know you and you donāt know me, now it may be that we know each other a little better.
This is a very simple solution, just use a custom action to set column (not user specific) to block when someone click on reservation and another action, to set to open, when someone click cancel. Than in filters use that column to hide block items.
You can also add another column to set a timestamps, so it will set back to open after specific time in case someone will exit app without clicking cancel.
This is not a true lock. Think about two apps running on different devices say A and B. Device A looks at the value and sees it is ānot lockedā, but B set the value 2 seconds prior and A has not been been updated with the value. Now both A and B think they have the item locked. So yes it does limit the amount of time that a conflict can occur to the update time, but it is not a true locking mechanism.
Not that this is a really big deal butā¦
Also I have a spreadsheet backing this application so now I have 2 (or more) edits happening that will push me over the limit for a Basic app to a pro app.
It will work good, add a user email column next to a timestamps , and who ever have earlier time , will have submit button available, and the other person will have a massage that someone else is booking this item, and if the first user cancel or time outā¦ submit button will become available
Also, i thing it will lock it instantly, so this problem will not happen, you have to do function for this in glide. Not in Google sheets. Keep edits in glide table, and only submits write to g sheet, this will save you edits limit
No issues. I just had to voice how I felt. And we do know each other a little bit betterš
And I know you were just trying to help, so thank you
Here is an experiment for you to try to see that the lock will not happen instantly. Create an app that can write a specified value to a cell. Open 2 webpages to the app. Let me call one app A and the other B. In app A do a write of a value, watch app B and you will see it takes a few seconds for it to update. In those few seconds if app B did a read of the value it would not get the value written by app A.
This will never work for a true locking mechanism. It is unreliable.
This was the whole point of me asking for Glide to implement it at the server. Take a read of what Mark did, basically he setup a separate mechanism to do the lock. It would take some special processing like maybe a lock column that always went to the server to obtain the data but I am pretty sure they could do it.
with all do respectā¦ i have big experience with problems like that, and trust meā¦ i know what am talking about. read carefully my advicesā¦ i did mention that all functions need to be done in glide table, not in google sheetsā¦ that why you have a delay
I agree. With Glide not quite being Server/Client based, there is no way to prevent two users from updating a record at the same time. Both will be allowed to update their local database before the local databases sync to the glide server database. Then one userās update will randomly take precedence and overwrite the other before that latest update is resynced to the local database of both users. Those resyncs can take up to a few seconds between different users. So whoever got their update in last within that split second will win and have control over the record. The first user may have updated the record first, but will lose out when the second user overwrights and takes control before the first user update ever made it to the second userās local database.
yup. The only way that Iām aware of to work around this at the moment is to delegate all updates to a 3rd party (ie. Integromat) and implement some sort of queuing system external to Glide.
here, @Jeff_Hager @Darren_Murphy iād made you a sampleā¦ there is no way you can double book it, and also it have a timer to kick out undecidedā¦ 
No 3rd partyā¦ just Glide!
you have to log in for this to work. It have a 2-3 seconds delay, because i base it on google sheet