As you know, updates based pricing affected the way we allow the users to filter items.
We can use user specific column to build custom advanced filters using choice component. Now, every time the user changes a value, Glide counts as an update.
For a listing or directory app, a user can make multiple updates a day. What happens if the app got thousands of users per day?
As Glide hasn’t an advanced search filters, HOW ARE YOU DOING NOW?
I have an App ( a business listing App) that is built around this concept of using filters. The App is on starter plan and thus far I have not gone live with it because I keep expecting that Glide will do something about this which means I am paying $25 a month for nothing thus far.
I have seriously gotten to a point of considering other alternatives for this particular use case until Glide finds a workable & more affordable solution.
I don’t think App owners/creators should be “penalized” for lack of functionality or features and this is what it feels like to be honest.
These filters using USC’s are “work-arounds” that creators have had to come up with ONLY because there is no “proper” native way to filter and App creators should not have to pay for that in my opinion. This is where this updates explanation starts to be inconsistent because if you charge because of the changes being synced with Glide servers fair enough but I would love to know how that holds up for USC because the changes are not being synced with the servers but rather are done locally on the device unless I missed something about this whole thing.
But, USC columns actually are synced to the server. They are stored internally in Glide’s database. They are not stored locally on the device. There is a gray area if the user is not signed in, but it’s my understanding that even if a user is not signed in, the USC columns are still communicating with the database, so it still causes updates.
Think of USC columns like an invisible table that contains a Row ID, Email, and the stored Value. When you create a USC column, glide is essentially creating a sort of relation to this invisible table, using RowID and Email as the key, and creating a lookup to return that value specific to a user. But it’s all packaged up nicely as a simple USC column instead of having to create extra tables, multiple computed columns, and set column actions to set the value. If you export your data sometime, I believe you will see all of that USC data as a separate table in the export.
So, I think the problem for glide right now is that USC columns DO cause updates just like any other column that stores a value. Someone could really exploit that loophole if glide allowed updates to ignore USC columns. Someone would try to circumvent updates to store all permanent data in USC columns intead if only custom filters or custom form data.
Long story short, and to answer your question…USC columns are still just basic columns that store values in Glide’s database. They just work a little differently in where they are stored in that database and how they are retrieved and displayed.
Glide has mentioned that they should build more functionality for filtering, but I still think something like a session variable, or a value that’s always only local to the device, would provide the best flexibility in the long term.
Thanks for taking the time to explain Jeff. Much appreciated…
If I had the ear of those in power, I would advise them to temporarily not count changes on USC as updates as that kinda highlights the need for a better filter…
Most Glide developers overlooked that short coming because of the work-around using USC… but with that now not being as useful, it places a demand on the team to work on a better filter…
But I have faith in them that they will come up with an acceptable solution soon
And when I think about limitation causes by updates price based, Glide becomes not suitable for serious and valuable apps. Another example, I’ve in one app a feature to count and display visits and visitors on items using increment function, that means thousands of updates per day.