Glide Big Tables - Filters - Bumping into walls

Ask for Help
1

I want to use Glide Big Tables in all my apps. But Filtering them is an issue for most clients I work with…

Tables usually have rowIDs and related to each other. For example a clients table has a relation ship to deals table using clientID. We cannot filter or search deals within the clients table tab.
Or filter or search clients within the deals table. They are lookup columns and NO we don’t want to make them basic columns because we are using the RowID to connect both tables.

Is there any roadmap plan to make it possible to filter big tables using computed columns? How would someone redesign their backend to allow such functionality ..

2

It’s in the roadmap.

For a workaround, is it possible to write those IDs to a basic column every time the value is changed?

3

Thank you.
Good to know its on the roadmap.

I’d rather not write values to a basic column for a workaround.. its very difficult to maintain the correct value in those basic columns when other basic columns in the related tables are changed.

4

@rayo

image
image743×474 54.2 KB

Is this the filtering you are referencing (limited to 100 matches) or does it just not work.

@ThinhDinh I don’t see filter limits in this list from the Docs. Is there an updated or most robust example of what does/does not work in Big Tables vs Glide Tables?

Thx

5

Can you go into more details on how this is constructed? Maybe a loop workflow can help albeit it’s a bit costly?

I don’t have one, and yeah, that list does not include all limitations.

6

It certainly seems RowIDs should be a unique type of computed column and treated like a Basic column in this example. Is there something special about RowID other than their creation (which is computed). Otherwise they look like a duck and quack like a duck and….certainly walk like a basic column.

7

I’m not sure I follow your example. From what I understand, Rayo wasn’t able to do what he/she wants because those rowIDs are lookups.

8

In his example wasn’t the issue the filter (which I assumed was a query) based on RowID?

Cause I also have lots of relationships based on RowID in Glide tables and didn’t realize they wouldn’t/might not translate to a Big Table.

Or is the filter used in a layout component?

Thanks for any insights.

9

I assume this means it’s somewhat of a lookup, because if it’s a basic column you can use it.

You can’t use computed columns in filters in a bunch of components, that’s my context.

10

I’m sorry i wasn’t following the conversation.

A simple example.. in a Deals table the status of the deal can be a computed column

For example an if/else column
if deal cancelled timestamp is not empty - deal is cancelled
if deal delivered timestamp is not empty - deal is delivered etc..

this computed status column you cannot use as a filter in a Deals relation.
You would need to save the deal status as a text column every time any action is taken on the deal and only then you can filter by the status.

This could get even more complicated when deal status is not only related to columns within the deal’s table. For example on one project i have - if all items of a deal are fulfilled - then the deal status is changed to complete. if the deal is cancelled its changed to cancelled and many other status in between.

1 Like