Exactly this is on published pages.
30.01.2023 And reason is unsigned user
I hope, this is not bug. And we can said thanks to Santa David!
And yes it is looks like bug, because us still synchronized to server
Yes, it would be nice. But I’d be very surprised - Glide were pretty adamant that this would not be changed.
Any murmurs on this with all the upcoming enhancements to pages?
I haven’t heard anything.
1 Like
Now, i know: if user haven’t sign in - so User specific columns isn’t counted
If user already signed in - so all changes in User specific column are counted.
This mean we still need Session variable column which not syncing to server and not counted as edit and so.
2 Likes
So youre saying Guests using USC wont count again your Updates?
Yes
1 Like
That makes sense, because User Specific Values for users that aren’t signed in are transient. They aren’t synced with the Glide back end.
1 Like
If that’s the case, and they already have session variables, it might be easy to just turn them on (technically). They’d still need to set us up with a new column type so they aren’t all done that way, I guess.
What youre saying is if the current USCs can work for anonymous users, where essentially they will be reset after their session is over due to them not being saved to a specific user, why not implement that as a separate column type so we can save temp info?
1 Like
That was my goal with this request. A column type where data can be entered, but never needs to sync with Glide servers. Something that works the same whether you are signed in or not. Essentially a temporary value that only exists for the duration of the session, and only exists locally on the user’s device. Something that can be used for custom searching or custom forms, and can save on unnecessary updates counts for data that’s only needed for the computed columns that already run locally on the device…or for custom forms, where they will ultimately being written to normal basic columns when an action occurs.
9 Likes
Exactly. This really needs to be a thing. It’s sorely limiting our creativity with app design and UX.
8 Likes
@Jeff_Hager @Robert_Petitto
Aren’t you people talking directly to @david and the team?
Could it have something to do with the business model as this feature would result in less updates and thereby potentially letting people stay on cheaper tiers
I have also requested this from way way back. It would make lives so much easier - and enable us to create better solutions
We have some extra contact with the team but we are still just users in the end trying to make user friendly apps that have the flow and features we want. We can only express our wishes, and that’s about it. Glide ultimately makes the decisions, and I fully respect that.
Yes this would fundamentally reduce the number of updates and potentially Glide’s bottom line, but at the same time, many of us are trying to create workarounds to overcome certain shortcomings, by building things like Custom Forms, Custom Search, or real time calculators. To add…even though Swipe and Stopwatch are not overly popular and may or may not make it to Pages, I feel that there are certain cases where the swipe date or stopwatch start and duration values don’t necessarily need to be stored permanently in the database, but those values are required just to function.
I use custom forms in situations where native forms just don’t provide the functionality I need. I explain why in this post. Mastering the Mighty Single Value → WHOLE ROW - #17 by Jeff_Hager
I would gladly use a native form if it provided real time access to relation/lookup data and computed column values that I could then turn around and use to write directly to basic columns when I click on submit. Or in my case, the ability for a choice component to write BOTH the displayed and underlying value to the table.
I have a stopwatch in my app just because I can (even though it’s not really used). I don’t need the start and duration values for anything. I just wanted a functioning stopwatch in the app. If I ever wanted those values for anything, I would most likely have a button with an Add Row or Set Column action to permanently save the values…but I don’t. The stopwatch runs locally anyway, so why would it need to store anything in the database. I’m not saying this is the case for everyone. Sometimes people need those values in the database, and in those cases a Basic or USC column would be more appropriate.
Unfortunately for me, the use of custom forms, and the use of the stopwatch causes extra updates to occur. I could care less if the values are stored in a table, but I need them temporarily to get the functionality I need. All the work is being performed on my device in these cases and doesn’t really need the server to be involved. In the end, my custom form performs an Add Row or Set Column action (which should then understandably incur an update because I’m permanently storing the data). My stopwatch in my case has no reason to permanently store it’s values. Fortunately for me, I only have one fully active user, so I’m not over concerned about hitting any limits, but I also don’t think I could reasonably scale to a much larger number of users.
If certain data is only needed on the local device for a short period of time, or at least the duration of the session…and it doesn’t need to be permanently stored in the table on the server, then I see no reason for the extra overhead to sync and store the data long term.
I think there would be multiple benefits.
- Less syncing of data and communication with the server. Less bandwidth.
- Values that reset automatically whether you are signed in or not. Maybe a custom search that does hold on to your last search value.
- More freedom to build custom functionality.
- Maybe a mild security bonus, since the developer will never be able to access and see the contents of session variables.
I think the hardest part would be conveying to the app developer that the value entered in a session variable column will never be stored permanently. They would need to understand when and when not to use them. I think it’s fair to say that there are use cases when you need to use a Basic column (including USC), as well as cases when you only need a Session column (only ever used locally on the device).
My goal isn’t to score free updates. I respect Glide’s business plan and their target audience. My goal is to make it easier to expand the functionality of my app without the fear of being penalized for thinking outside the box. USC columns are halfway there when you aren’t signed in. Why not fork that ability to a different column type that acts the same way whether you are signed in or not.
Done ranting.
9 Likes
I just love the depths of your details, Jeff. You’re taking to the next level.
The info that the glide team (and the rest of us) is provided is beyond anything. I really do hope that the glide team actually picks up all the good info.
2 Likes
Hehe, yeah I get wordy…and a little passionate…sometimes.
1 Like
I second, third and fourth this! I rarely use native forms specifically for this reason (computed columns writing to basic columns).
This is a real use-cases/class that should be handled/billed in a different manner.
2 Likes
I was just thinking, as long as users are not signed in, could we use custom forms that write to a helper Table of just usc and use an Add Row action to add all the USC to our real table at once? Therefore our custom form would only use 1 update?
1 Like