🧲 The QUERY Column: One Column to Rule Them All!

:wave: Hey fellow Gliders!

:mechanical_arm: 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:
:point_right: Filter
:point_right: Sort AND
:point_right: Limit related data in ONE COLUMN

Learn more:


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.


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.



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.


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!


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.

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:

  1. 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.
  2. 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.
  3. Apparently, Relation is slower than Query, so for performance considerations, it would be better to use Relation rather than Query.
  4. 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."
  5. 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.


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.

1 Like

What are your use cases in the new Glide Apps for a self-relation though?