You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/pages/product/apis-integrations/sql-api/joins.mdx
+34-18Lines changed: 34 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,19 @@
1
+
# Joins in the SQL API
2
+
1
3
## Views
2
4
3
-
The best practice to query joins using SQL API is to use views. This is the preferred way of
4
-
joining as it provides you control over the joining path for complex use cases.
5
-
While BI tools would see the view as a table, in fact, no materialization is done until Cube is queried.
6
-
Whenever Cube view is queried through SQL API, Cube tries to maximize member pushdown so only required parts of the view are materialized at query time.
7
-
Cube also solves fan and chasm traps based on the dimensions selected in the query, so if measure aggregation types are properly set up, you will see correct results in BI tools even though cubes and views are seen just as tables.
5
+
The best practice is to use [views][ref-views] to specify explicit [join
6
+
paths][ref-join-paths] for SQL API queries.
7
+
8
+
While BI tools would see a view as a table, in fact, no materialization is performed
9
+
until Cube is queried through the SQL API. At the query time, Cube will try to maximize
10
+
member pushdown, so only required parts of the view are materialized at query time.
11
+
12
+
Cube also solves fan and chasm traps based on the dimensions selected in the query, so
13
+
if measure aggregation types are properly set up, you will see correct results in BI tools
14
+
even though cubes and views are seen just as tables.
15
+
16
+
Consider the following data model:
8
17
9
18
<CodeTabs>
10
19
@@ -33,7 +42,8 @@ view(`orders_users`, {
33
42
includes: ['status', 'count']
34
43
},
35
44
{
36
-
join_path: orders,
45
+
join_path: orders.users,
46
+
prefix: true,
37
47
includes: ['id', 'city', 'state']
38
48
}
39
49
]
@@ -42,11 +52,12 @@ view(`orders_users`, {
42
52
43
53
</CodeTabs>
44
54
45
-
Now, it is possible to get orders count by users city with the following query.
55
+
With this data model, here's how you can get orders count by users' cities:
46
56
47
57
```sql
48
-
cube=>SELECT count, city FROM orders_users;
49
-
count | user_city
58
+
cube=>SELECT MEASURE(count) AS count, users_city FROM orders_users GROUP BY2;
59
+
60
+
count | users_city
50
61
-------+---------------
51
62
1416 | Los Angeles
52
63
1412 | Seattle
@@ -59,17 +70,18 @@ cube=> SELECT count, city FROM orders_users;
59
70
(8 rows)
60
71
```
61
72
62
-
#Joins
73
+
## `CROSS JOIN` and `__cubeJoinField`
63
74
64
-
The SQL API supports joins through `__cubeJoinField` virtual column, which allows end users to control how specific cubes are joined.
65
-
This is considered advanced functionality, and views should be used where possible.
66
-
Join can also be done through `CROSS JOIN`. Usage
67
-
of `__cubeJoinField` in a join instructs Cube to perform join as it's defined in
68
-
a data model. Cube generates the correct joining conditions for the underlying
69
-
data source.
75
+
The SQL API also supports joins through the `__cubeJoinField` virtual column, which
76
+
allows to control how specific cubes are joined. This is considered an advanced
77
+
functionality, and views should be used where possible. Join can also be done through
78
+
`CROSS JOIN`.
79
+
80
+
Usage of `CROSS JOIN` or `__cubeJoinField` instructs Cube to perform join as it's defined
81
+
in a data model while using provided cubes as [join hints][ref-join-hints].
70
82
71
83
For example, the following query joins the `orders` and `products` tables under
72
-
the hood with`orders.product_id = products.id`, exactly the same way as the
84
+
the hood on`orders.product_id = products.id`, exactly the same way as the
73
85
REST API query does:
74
86
75
87
```sql
@@ -189,6 +201,10 @@ LIMIT 5;
189
201
(2 rows)
190
202
```
191
203
192
-
Please note even if `product_description` is in the inner selection, it isn't
204
+
Please note that, even if `product_description` is in the inner selection, it isn't
193
205
evaluated in the final query as it isn't used in any way.
0 commit comments