Really nice video Bob, as always.
1 Like
Really glad I bumped into this post, itās good timing as Iāve been meaning to āclean upā my overly complicated data tables, with their proliferation of columns. Plus I always pick up some tips along the way from your videos.
If you have any suggestions for how to methodically swap out a thicket of ITE columns and relations for query columns Iād love to hear your approach!
This is really helpful. One question that I have been puzzling on when experimenting with this that also comes up in the video.
Take your last example @Robert_Petitto. The first column you create in that example (priorityTasks) could also be accomplished and displayed, as you demonstrate, using the filter on the component right? So the real magic comes from the additional columns that you create to leverage that first query, right?
If you were just going to stop at displaying the results of the first query, is there an advantage to using the query over a filter?
Find All Uses is your best friend when it comes to this.
1 Like
Correct. If youāre only interested in displaying a filtered/sorted list, you can simply do that through the component settings on the front end. The power of this component is if you need to do any sort of calculations or make special conditional relation to data in your data table.
2 Likes
Perhaps not a direct answer to your question to Bob, but⦠I have a general rule of thumb - any time I find myself wanting to add more than one filter condition, I stop myself. And instead I create the filtering logic in the data editor. As a result, I almost never have more than one filter condition on any component, even for the most complex of use cases. This approach has paid dividends for me over and over again.
8 Likes
Correct!
I typically start with the very last column in the āchainā of computed columns. āWhich column am I ultimately trying to display/calculateā. Then Iāll build a query to replace that column. Then Iāll backtrack using the Find all uses
functionality and start redircting/deleting columns working backwards.
1 Like
Thatās a good tip. Also probably some minor advantage from a workflow perspective if you want to display the results of the query in different places, over copying and pasting the filtered component.
Yes, thatās right. And where it really pays off is when you have a really complex set of filter conditions that need to be applied to a whole bunch of components/containers. Just create the logic once in the Data Editor, and then apply it wherever itās needed.
3 Likes
Remember that the Query is either -all- āandā or -all- āorā. No mixing query like a where clause such as (if (a is (b or c) and (d is (e or f))). So it behooves you to design your data to resolve as a query that filters either just AND or OR like you have preached for years!
The āthis rowā feature is awesome cause it allows a row to be the owner of all the āfilterā fields vastly simplifying dashboards!
4 Likes
In response to your Rank query, we are also able to set multiple ORās, assuming your rank page is sorted numerically, and limit to 1 while sorting from bottom to top. This helped me achieve 3 optional criteria a client could meet in order to ārankā into a new tier. Very powerful/flexible.
1 Like
Great idea! Reverse sorting is a trick I donāt often employ. How do you use reverse table sorting elsewhere?
I played with Query, what a neat computed column. Iāve been asking myself questions, maybe some of you might have gone through the process as well:
- Query is similar to Relation, possibly simpler to set up. The filter by, this row, sort by and limit features make this column powerful. So my initial thought was that Iāll be using Query only from now onwards and Glide will probably eventually phase out Relation.
- Query is a Multiple Relation.
And I havenāt been able to get the same output as a self Relation with Query. So really, as a function Relation is not yet included in Query and Query cannot yet replace Relation. Has anybody managed to get a output similar to a self Relation by any chance? EDIT: In the end I was able to create a self-Relation with Query.
- Apparently, Relation is slower than Query, so for performance considerations, it would be better to use Relation rather than Query.
- Why have two computed columns that output results that are so similar in some cases (multiple relations), yet quite different in others? It now feels that based on the use case, weāll be having to tell ourselves āThough Relation and Query output something similar, I just used Query, but for my use case I should have used Relation instead."
- Query outputs multiple rows, as it should, I assume. Relation defaults to single (or what we should call first). But really, shouldnāt Relation default to multiple? And what is this single/first setting anyway, is that a thing in traditional programming? The self single Relation is useful in Glide to create unique lists of rows, but it got me wondering why single Relation outputs the first row found. Considering the data in tables is not ordered, it feels quite arbitrary that a single Relation would return the first result.
Hopefully, some of these questions will find answers and possibly trigger a few interesting exchanges.
2 Likes
You can use Single Value columns as a replacement to Lookup columns.
2 Likes
I meant self Relation at one point in my questions, thatās the main I havenāt managed to achieve.
1 Like
What are your use cases in the new Glide Apps for a self-relation though?