If I have a table Orders
My orders tab could be based on this table and filtered for example isNewOrder = True.
that will show all new orders only
but hidden on the screen are all the information of the other orders
I could also create a new glide table with 1 row only called ‘new orders’ and make a multiple relation to the Orders Table where isNewOrder = True.
Then create an inline list on my tab based on this relation… in this case security wise is the information of the other rows hidden?
Hidden from view, yes. Securely hidden, no.
Simple rule of thumb: If you reference one row in a table anywhere in your app, then every single row in that table will be downloaded to the users device. And the only thing that changes that is Row Owners.
I don’t know for a fact, but I would say probably not.
Of the two options - in table filtering vs relation - I’ve have/do use both methods, but these days I find myself leaning more towards using in table filtering instead of relations. But that’s mainly because there was a UI bug with relation based Inline Lists a few months ago that was causing me all sorts of headaches, and so I started using an alternative method. I honestly don’t think one is a better or more efficient method than the other, it just comes down to a mix of personal preference and whichever works best for the use case.
Depending on case, use Filters or Relations can be the solution to make your APP simpler or faster (by avoiding creating many columns).
The main advantage of using relations is that we can have stats easily via Rollup directly. Instead, with filters, we have to create new columns to do calculations and to me, it’s overburden the APP.
In some cases - but not all - it’s possible to get the best of both worlds.
For example, let’s say you’re using the table filtering method and you use one or more if-then-else columns to determine which rows should be shown. Normally, you might just return true for the matching rows. But what you can do instead is return some value - price, quantity, whatever. And then you can do your rollup on that. Your filter will still work, you just need to adjust it to ignore empty values.
Of course where this becomes inefficient is where you need to do several rollups on different column values. In that case, then yeah, it’s probably better to use a relation
I have a table of Orders items with around 5000 rows.
I have a column isIssue = True if there is an issue with this item. There are around 50 items with issues.
I created 3 Tabs and added a Glide Search to each.
Based on the Order items Table directly… List Layout… Filtered by item isIssue = True.
Based on a 1 row Glide Table called item-issues. Detail Layout. I displayed a list of items directly from the Items Detail Table with a filter showing only isIssue = True
Based on the same Glide Table as 2. but instead of displaying a list. I created a multiple relation inside the 1 row Glide Table. Filter = True. Relation where Item in Order Items Table is Issue = True…
Then I displayed the results of the relation in the detail layout.
The speed of Glide default search was huge between option 3 and option 1.
With a relation in the table. Searching the table showed no delay… While in Option 2 there was small freeze before results appeared.
In option 1… the app froze !! (to be more accurate… it froze due to having too many template columns in the table, i removed most and option 1 & 2 are very similar in time just that creating a relation in option 3 appears to be obviously faster
note that there is a small bug in Glide with regards to relations and the value True.
if you create a boolean column and check the box. then change it to Text it will show as ‘true’ lowercase.
so that boolean column in a relation to another column If/Else (returning True/False) will not work. unless you either change the if/else to lowercase or change the boolean to text… update to True uppercase then change column back to boolean.
Sometimes I’ll create a template column that contains just the word true for the purpose of creating a relation with a boolean column. But again, I always use all lowercase, so I’ve never had a problem with it.
