Iāve experimented a little further, hereās how far I got:
Parent-to-children Relation. I got the same output with a Query.
Children-to-single-parent Relation. I got the same output with a Query.
Children-to-many-parents Relation. I got the same output with a Query.
Self-relation to create a unique list. I got the same output with a Query.
For those use cases which seem to be the main ones, Relation is included in Query. Meaning I might as well ditch Relation. Relation seems to be redundant now.
This does not take into account performance considerations.
I might still use a self-relation to determine the unique rows of a table (along a given column). For instance if name has a, b, c, a, b, c, then the output on the first three rows would be a, b, c (self-relation with single match, lookup.RowID, if-the-else where lookup.RowID == RowID).
Exactly. Querying IS SUPER powerful, but querying a huge table and using lots of conditions wonāt be AS efficient as creating the relation first and then querying the relationā¦but then youāre using 2 computed columns, so itās a trade off I guess.
Clearly (I hesitate to use this term) Query is meant to replace Relation. Query is more powerful than Relation, itās somewhat easier to set up, itās more logical, Relation is included in Query. The only issue is that Relation is still quicker than Query, which is an issue if one would like to use Query only instead of Relation.
We now have two computed columns that are extremely similar, it feels messy. Itās like those 4 title components that are basically 1 single component, or card and grid that are basically 1 style.
I havenāt tried it yet, but I donāt think I would want to query a relation. Since Relation is included in Query, that would be like querying a Query. That doesnāt feel right.
So what would be less arbitrary?
The third from the start?
The second last one?
The one in the middle?
What if there was only one match?
This is a common pattern in computing. As soon as you find a match, exit the loop and move on.
Think about the way that the if-then-else column works, itās exactly the same. The first condition that matches determines the result
Phrasing it like you did makes so much more sense to me. I never saw a single Relation as an iterative loop but rather as a vertical scan. Perhaps these are the same but loop plus find match plus exit loop makes more sense to me. Programming never ceases to amaze me.
What I did to achieve this with Query was filter to find all (since Query is a match multiple) then limit to 1 (first from the bottom or top). With Query we seem to lose this ability to exit the loop when a match is found.
When I read the term āself-relationā something strange happens in my eyes
In my point of view, a self-relation (also called self-join) should be avoided and not used as much as possible.
A self-join is a join in which a table is joined with itself, and when used, generally indicates that the table is non-normalized in 90% of cases.
This may not be a problem for a small table (perhaps less than 2k-3k rows), but using a large, complex table with higher concurrency (moves) will lead to poor performance and degrade your query response time. It is a fact!
Google even states that this trick should be avoided if you are going to use their BigQuery database, which is column-based and not row-based like traditional RDBMS databases (what we use in Glide).
Is a relation faster than a query? I think so and the reason is because the Query column needs to classify and discard the data based on the filters set on it. The query has more work and calculations to do than a relation.
Instead, the relation simply joins 2 tables using a (common) key field/column between them and creates a new and larger virtual table ready to be parsed.
We could have had a better tool if we could set Query to the fields/columns to use and not just the filters.
I mean, now we are using a standard Query clause like this in Glide:
Select *
From MyTable
Where Filter1 AND|OR Filter2 AND|OR ā¦ FilterN
Order by Column ā¦ ASC|DESC;
Limit N
but it could be better if we can get the following:
Select Column1, Column2, Column3 ā¦
From MyTable
Where Filter1 AND|OR Filter2 AND|OR ā¦ FilterN
Order by Column ā¦ ASC|DESC;
Limit N
A query with few columns and no filters will be faster than the current Query column or even the current Relation column.
Can we have this enhancement for the next Query version?
I agree, Query is practical for cohort analysis, i.e. reports. With Relation, reporting requires a Template column, a self multiple Relation and a Rollup. With Query, reporting requires a Query and a Rollup. Query is much easier to understand than Template + self Relation.
If you need to create a traditional Relation from a query, you can always using Single Value to pull in the first queried itemās row ID, then create a relation using that. Not hard to figure out but just a tip I came across.
Havenāt tested this extensively, but having a sort option in query, combined with the sort option in a component allows for secondary sorting. So you can achieve this:
This achieves the goal of keeping the data tables as clean and uncluttered as possible, but it also creates a logical separation of concerns and makes maintenance/debugging much simpler. Because each report has itās own table, I know exactly where to look if something breaks.
