It occurred to me i may be causing myself a headache in the future and realised i am not quite sure how this all works…
My Users table has 6 storage columns i use for temporary storage for custom form screens and various queries (usually as filters).
Do these computations re-run each time i edit the temporary coloumns? In all corners of the app? Or only if I actually need data from that query in that moment?
Is my current setup a problem? if so, how should it be done? Lastly, if a user table has row owners, do i need to use user-specific columns? does it matter?
Most computed columns are evaluated directly on the user’s device. There are certain cases when they are evaluated server side, but generally it’s the user device doing most of the work.
Computed columns usually evaluate the first time it’s needed after the app is loaded/opened on the user’s device. After that it’s usually reevaluated any time the source date that feeds those computed columns is changed.
You should be fine. The data is still syncing to Glide servers, but there really isn’t any alternative. In the past I’ve requested session type variables that only live locally and act as temporary placeholders for the duration of the session, while also helping to reduce the amount of data sync I/O on the Glide servers, but that request has never come to fruition. At the very least, it would be a lot more useful if native forms could still do computations without relying on data being stored to a table before being submitted. In some cases, what you are doing is the only option, so you jist have to do what works.
Row Owners really shouldn’t be a factor when it comes to using user specific columns. If you are utilizing the user profile as temporary storage, then each user will always be working with their own row regardless if you are using row owners or not. Where it might be a different story is if you have a screen connected to the user table without row owners, without any sort of filtering applied to the screen, as well as writing directly to the table instead of writing to the user profile. In that case, you may inadvertently have each user updating the same first row in the user table. Proper setup would avoid that.
The only time you need to use user specific columns is whenever you would expect multiple users to be updating the same column in the same row, but you don’t want users overwriting each other, meaning you want each user to have a unique experience. If each user has their own row, then you typically don’t need user specific columns. Only use user specific columns when you want each user to store a unique value in the same cell.
If they re-evaluate when source data that feeds them change, i have a follow up question.
Currently “Storage 1” column in the users table gets used for many different purposes in many different parts of the app. Meaning its possible that source data for many queries changes all the time. (i know i said query filters in OP, but just a thought)
Would it be better to have more columns with each function (or group of) having its own column so working on Invoices doesn’t trigger re-evaluation in the field reporting tab. Side benefit it would mean i could have nice clean labels for columns instead of “Storage 1” with 60 “used by” entries.
I have a habit of always using User Specific columns in the User Profile row for these types of use cases. That’s mostly a hangover from the days where the only Data Source was a Google Sheet, and I didn’t want these extra columns appearing in my Google Sheet, but I also like the fact that it provides a visual queue that these columns don’t contain “real” data. The only exception I make is in the case where I need to provide admin level view to the values in these columns (which is pretty rare).
I guess it’s hard to say, and probably comes down to personal preference or app performance. If everything is performing as expected, I don’t usually worry about how I have everything structured. If I have performance issues, then I try to reduce as many computed columns as I can. Overall, I’d say go for what makes sense to you to keep everything organized, and then see if the app remains responsive.