If someone wanted to add 336 columns to the users’ table in Glide tables, storing a boolean value in each…
Plus 1 array column combining all 336 boolean values…
Are there drawbacks to expect from that?
And if yes, what would the number of users have to be when those drawbacks become noticeable?
I think it’s doable, but I would question the need for so many columns. If it’s possible to formulate those values as a comma delimited list, then you could use a Split Text column to create an array. That would only be 1 Basic Text column for the comma delimited list, and 1 Split Text column to split it into an array. Two columns are much easier to manage as opposed to 336 individual columns. But again, that all depends on your particular use case.
In this particular use case, we first need to get the data from the user.
And it seems that the only practical way to get that data from the user in a Glide app is to have the user tap the relevant checkboxes.
The checkboxes will be organized in a few groups to make things easy to see and understand at a glance. And the user is expected to leave the vast majority of checkboxes unchecked.
So, they’ll only need to tap a few times per group and will be able to copy the checked checkboxes from one group to another with a single tap.
Overall, out of 336 checkboxes, the user would only check 20 or 30 max.
Still, the values for all 336 checkboxes would need to be stored.
Thus the question.
Fundamentally, we only need one array containing 336 boolean values for each user. That’s the only data we need to do work.
But we need to get that data somehow from the user.
And the user needs to be able to update that data.
P.S.
Hmm… actually… after I just added that previous paragraph, I got an idea…
What if we had a temporary table i.e. table for temporary data with 336 columns…
That way, after getting the data from the user and creating an array containing 336 boolean values, we’d just write the array into the users’ table, delete the row in the temp table and be done with it!
Could that work?
Are you able to put all 335 choices in a separate table, with 1 column for each set of choices?
Then a user can use a choice component with multiselect where the user can store all their answers in only a few columns in the User Table
I have considered a choice component with multiselect but it wouldn’t really work in this case.
The user needs to mark in which of the half-hour slots on a weekday they are available (in general).
So, 48 half-hour slots in a day, 7 days a week.
But for doing all the computational work and displaying stuff to the user, we only really need one array for all 336 half-hour slots in a week.
P.S.
Just realized that there’s a handy “Append Array” option in the Glide tables that makes it possible to add one array to the end of another.
So, maybe we can get away with just one set of 48 columns in the temporary table by getting the user to add data for each day of the week separately.
48 columns for temporary data seems so much better than 336. 
Why not?
I’d do the following:
Using the above approach, you can either write everything directly into a single column in your User Profile table, or 7 separate columns (one for each day of the week) and then combine them.
Hmm… sounds very interesting.
Will try this out.
I just never handled a choice component with multiselect here.
So, totally clueless about that at the moment. (just thought of it in terms of traditional old HTML select type of thing)
But your approach seems very interesting and promising.
I was thinking if you use one for each day of the week, then you could present it using the chips layout, and it wouldn’t be too clunky.
Use a single list for all 7, and filter each one appropriately (perhaps add a “Day of the Week” column to your helper table).
This is starting to look great!
All 48 of those chips for the whole day fit comfortably on the screen of my phone. Thanks for suggesting that!
The only thing I’m yet to figure out is this part:
P.S.
Come to think of it, I’ll probably have to use a separate column for each day of the week.
Because those chips only produce a string like this:
"06.30,07.00,07.30,08.00,17.00,17.30,18.00,18.30,19.00,19.30,20.00"
and I first have to convert that into an array of 48 boolean values like this:
[false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, true, true, true, true, true, true, true, false, false, false, false, false, false, false]
Then, I’ll have to concatenate all 7 of those arrays into one for actual use.
But hey, 7 columns (or 14 for that matter) is so much better than 336.
Thanks a lot!
I guess I don’t really know what you’re doing with all those booleans - or if they absolutely must be booleans. But my idea was something like the following:
First, the helper table:
I just added a handful of rows - enough to make the pattern obvious.
Then configure each of the choice components so that:
So the end result would be something like the following:
As the rows in the helper table are numbered, it would be a simple matter to join those, convert to an array, and then relate to the helper table to get a list of all selected times for all days.
But again, I’m not sure if that was the end goal or not (again, I don’t know what you are doing with the boolean values).
Really appreciate your screenshots. That helped a lot. Thank you!
But regarding this bit things are still unclear:
This is what I have and it works great for filtering for ONE day:
But I can’t seem to figure out how to switch between different days in this scenario.
I can display the chips for any one day of the week,
but to get user’s input for every day, I need to be able to switch between different days.
How do you do that?
I must be missing something obvious.
P.S.
I guess that once the user selects a weekday,
I have to send them to a separate screen for time selection, right?
The boolean values were just to have an easy way to convert any time zone to one common time zone for comparison purposes i.e. to check whether any 2 given users have availability overlap for a meeting.
But if I can get row IDs (0 to 335) as you suggested, then boolean values are no longer needed for such conversion and comparison.
Like this:
One thing to watch out for if your screen is sitting on top of your user profiles table is that you are writing to the correct row. If you’re using row owners (as I am in that video), then it’s not a problem. But if you aren’t, then you’ll need to ensure that your screen is filtered to the signed in users row.
Amazing! That helped a lot.
You are my hero.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
