Session Variable Column

I understand that simplicity is key. I don’t disagree, but so many times as a 20+ year software engineer, I’ve fought for days with Glide’s current limitations to do something that would be super simple with a few minutes spent writing a few lines of code, or a small tweak or addition to the built in feature set. I honestly don’t think Glide can solve every possible use case without adding some level of complexity. Glide has changed immensely in the past 5 years and they do a lot of things very well, but to build specific simplified features that would cater to most if not all scenarios would lead to feature overload. Are there any feature that exists now that you use regularly, but would have said is too complicated 3 or 4 years ago? It’s an evolving ecosystem that needs to adapt to change and requirements as it matures. People are going to forever need more and more capabilities and push the envelope to achieve their desired goals.

I have a specific use case where I need to save both the displayed and the underlying value from a choice component, but for half of those choices I need the user to manually enter a custom underlying value instead of saving the underlying value from the choice, and subsequently display the underlying value on the screen either way as a confirmation to the user before submitting the form. This is only achievable with a custom form, which requires USC columns, which includes unnecessary updates. I don’t forsee Glide ever building something for this specific of a use case, but it’s something I absolutely need, and I don’t know of any other way to pull it off without some complicated action sequence or backend scripting which still wouldn’t completely solve the problem. To me a session variable column would be the simplest solution as I can build a custom form that works the way I need it to and does provide the update hit to temporarily store values and performance computations before the form is submitted.

I have another use case where I use a choice component to control component visibility. I sincerely hope Glide makes a native tabbed container, but will it’s design fit my app style? Will it allow me to place containers or another tab container within that tab container? I could use buttons or an action row that opens an overlay, but the overlay has it’s own issues especially when you start to open overlays on top of overlays. I can wait months or years for Glide to ‘maybe’ address each and every one of every user’s use cases, or they can make one single change which would address a whole host of use cases for several different users. I don’t want to wait for a maybe when I need something now. For now USC is the only option for me but it’s not ideal, especially at scale.

It’s like comparing Microsoft Notepad to Microsoft Word. Notepad is simple and easy to use. You could argue that text written in notepad will convey the exact same message as it would with a word document, but I’m not going to write business documents with it. I need custom formatting. I need dynamic content. Word is complicated for sure, but it’s way more flexible compared to Notepad. I don’t have to understand or use every feature of Word, but if and when I need them they are there, whereas Notepad is severely limited. Would you submit your CV to a potential employer written in Notepad or written in Word?

I also think it’s advantageous for the certificated experts to confidently tell their high paying customers that they can build the customers wishes rather than say that Glide is only for simple use cases and not meant for advanced logic or design.

I get where you are coming from, I honestly do, and every new feature should be thought out very carefully by the Glide team to be simple to use and understand, but this request would open up so many possibilities to make Glide more powerful.

3 Likes

I don’t know, but maybe this feature is a backdoor for power users, who can use Glide on a free plan. And maybe it is main reason Glide still not implement it until now.

1 Like

That thought has crossed my mind, and I’ve tried to give considerable thought to this feature. I do want to consider Glide’s best interest regarding this, but if people are backdooring on a free plan, they are already doing it unsafely using USC columns without sign in and against Glide terms and conditions. Seems to me that those honest people on paid plans using Glide’s native sign in get one less feature than those who choose not to use sign in.

If values are not saved to the database using a session variable column, then I’m not sure how far someone could exploit it. I can think of a few ways that are typically unsafe and unsecure, but that’s not much different than what’s possible now.

I wouldn’t be opposed to it being a feature only available on plans if that’s what it takes.

4 Likes

Also, I don’t see how it’s against Glide’s interest since it’s not utilizing their servers/bandwidth. It’s local on the device.

Additionally, something like this is quite important when utilizing user specific columns for filtering purposes as we have applications utilized by power users and you don’t want filters syncing between many open tabs!

Local variables is a very very basic and important feature needed for proper functional large scale applications. @david

Can we have another type of column option, ‘session specific’?

FYI, today we released new pricing. On the new plans, app users can Add, Edit, Delete unlimited values in Glide Tables and it does not use updates–this is a good alternative to the topic.

8 Likes

I think it will solve my needs.

Edit: Well, minus the automatic clearing when the session is closed.

1 Like

I don’t feel safe with this decision by Glide. Don’t data updates on glide tables cost glide money? how can they become free. I guess the past year the main focus of glide developers was to save updates… but now, favorites, likes, custom forms will be everywhere on every screen…
Should I feel secure to start using all these … or is Glide going to find its decision was incorrect and roll back updates on Add, Edit & Deletes soon

A self hosted database is probably a lot cheaper than the cost to synchronize with a third party database. If a project is only using Glide tables, this cuts down on the additional costs that probably existed to sync with Google.

There’s a cost associated with updates no matter what, but I think the costs to use Glide tables are probably minimal in Glide’s eyes.

They know about this request and have acknowledged the new plans as an alternative, so I feel that it would be a suitable alternative and I fully plan to take advantage of it, if and when I start to use the new plans. In any case, integrations and advanced feature are probably more profitable than updates in the long run.

I think the update concept is not so much about updating data, but more about gauging value for the customer.

1 Like

Personally, I’m feeling 98.5% secure (it could never be 100…). Glide has wanted to make no-updates-in-Glide-Tables a reality for at least a year. Now that they’re pulling the trigger, I feel confident that it will stay.

3 Likes

Correct me if i’m wrong. I am on a business plan. I won’t get free updates until I upgrade to one of the new plans glide rolled out today, right?

Correct.

Jeff if you don’t mind just 1 last question … glide mentions several times computed column updates in its docs and community
e.g.

by computed columns they only mean ones computed using a 3rd party integration …(open ai etc…) right?

nothing to do with the ones computed on the user device… templates… math… etc

1 Like

Yes, I believe you are correct.

Computed columns that use integrations will still count updates when the value changes. These computed columns are usually computed server side. The number of updates should be indicated when configuring the column in the data editor.

Other computed columns that are computed client side do not count updates since no processing occurs on the server.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.