Hey fellow Gliders!
Glide just got even more powerful by introducing the QUERY column!
No more complex, multi-column setup to achieve conditional relations.
The Query column can:
Filter
Sort AND
Limit related data in ONE COLUMN
Learn more:
No more complex, multi-column setup to achieve conditional relations.
The Query column can:
Filter
Sort AND
Limit related data in ONE COLUMN
Learn more:
Really nice video Bob, as always.
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.
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.
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.
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.
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.
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!
The āthis rowā feature is awesome cause it allows a row to be the owner of all the āfilterā fields vastly simplifying dashboards!
Ya! Game changing!
Bob the master of how to
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.
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:
Hopefully, some of these questions will find answers and possibly trigger a few interesting exchanges.
Query is a Multiple Relation. And I havenāt been able to get the same output as a Single 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 single Relation by any chance?
You can use Single Value columns as a replacement to Lookup columns.
I meant self Relation at one point in my questions, thatās the main I havenāt managed to achieve.
What are your use cases in the new Glide Apps for a self-relation though?