docs: Update join relationship types

docs/content/Caching/Getting-Started-Pre-Aggregations.mdx

@@ -167,8 +167,8 @@ receives via the API. The process for selection is summarized below:
 
    - The pre-aggregation contains all dimensions, filter dimensions and leaf
      measures from the query
-   - The measures aren't multiplied ([via a `hasMany`
-     relation][ref-schema-joins-hasmany])
+   - The measures aren't multiplied ([via a `one_to_many`
+     relationship][ref-schema-joins-rel])
 
 3. If no, then check if
 
@@ -197,7 +197,7 @@ cube(`LineItems`, {
   joins: {
     Orders: {
       sql: `${CUBE}.order_id = ${Orders.id}`,
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
     },
   },
 
@@ -425,7 +425,7 @@ To recap what we've learnt so far:
 
 - **Additive measures** are measures whose values can be added together
 
-- **Multiplied measures** are measures that define `hasMany` relations
+- **Multiplied measures** are measures that define `one_to_many` relationships
 
 - **Leaf measures** are measures that do not reference any other measures in
   their definition
@@ -488,7 +488,7 @@ Some extra considerations for pre-aggregation selection:
   /caching/using-pre-aggregations#pre-aggregations-storage
 [ref-schema-dims]: /schema/reference/dimensions
 [ref-schema-joins]: /schema/reference/joins
-[ref-schema-joins-hasmany]: /schema/reference/joins#relationship
+[ref-schema-joins-rel]: /schema/reference/joins#relationship
 [ref-schema-preaggs]: /schema/reference/pre-aggregations
 [ref-schema-preaggs-origsql]:
   /schema/reference/pre-aggregations#type-originalsql

docs/content/Caching/Using-Pre-Aggregations.mdx

@@ -582,7 +582,7 @@ cube(`Orders`, {
   joins: {
     Users: {
       sql: `${CUBE.user_id} = ${Users.id}`,
-      relationship: `belongsTo`
+      relationship: `many_to_one`
     },
   },
 });

docs/content/Examples-Tutorials-Recipes/Recipes/column-based-access.mdx

@@ -19,7 +19,7 @@ To implement column-based access, we will use supplier's email from a
 [`queryRewrite`](https://cube.dev/docs/security/context#using-query-rewrite)
 extension point to manage data access.
 
-We have `Products` and `Suppliers` cubes with a `hasOne` relationship from
+We have `Products` and `Suppliers` cubes with a `many_to_one` relationship from
 products to suppliers:
 
 ```javascript
@@ -28,7 +28,7 @@ cube(`Products`, {
 
   joins: {
     Suppliers: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.supplier_id = ${Suppliers.id}`,
     },
   },

docs/content/Examples-Tutorials-Recipes/Recipes/entity-attribute-value.mdx

@@ -26,7 +26,7 @@ cube(`Users`, {
 
   joins: {
     Orders: {
-      relationship: 'hasMany',
+      relationship: 'one_to_many',
       sql: `${CUBE}.id = ${Orders.userId}`,
     },
   },

docs/content/Examples-Tutorials-Recipes/Recipes/event-analytics.mdx

@@ -254,9 +254,10 @@ The next step is to identify the events contained within the session and the
 events ending the session. It’s required to get metrics such as session duration
 and events per session, or to identify sessions where specific events occurred
 (we’re going to use that for funnel analysis later on). We’re going to
-[declare join](/schema/reference/joins), that Events `belongsTo` Sessions and a
-specify condition, such as all users' events from session start (inclusive) till
-the start of the next session (exclusive) belong to that session.
+[declare a join](/schema/reference/joins), that Events have a `many_to_one`
+relation to Sessions, and specify a condition, such as all users' events from
+session start (inclusive) till the start of the next session (exclusive) belong
+to that session.
 
 ```javascript
 cube('Events', {
@@ -265,7 +266,7 @@ cube('Events', {
   // Add the joins block to the Events cube
   joins: {
     Sessions: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `
         ${Events.anonymousId} = ${Sessions.anonymousId}
         AND ${Events.timestamp} >= ${Sessions.startAt}
@@ -382,7 +383,7 @@ cube('Sessions', {
   // Declare this joins block in the Sessions cube
   joins: {
     Identifies: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${Identifies.anonymousId} = ${Sessions.anonymousId}`
     }
   },

docs/content/Examples-Tutorials-Recipes/Recipes/funnels.mdx

@@ -264,7 +264,7 @@ steps: [
 
 In order to provide additional dimensions, funnels can be joined with other
 cubes using `user_id` at the first step of a funnel. This will always use a
-`belongsTo` relationship, so hence you should always join with the corresponding
+`many_to_one` relationship, hence you should always join with the corresponding
 user cube. Here, by 'user' we understand this to be any entity that can go
 through a sequence of steps within funnel. It could be a real web user with an
 auto assigned ID or a specific email sent by an email automation that goes
@@ -276,7 +276,7 @@ following:
 cube(`PurchaseFunnel`, {
   joins: {
     Users: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.first_step_user_id = ${Users.id}`,
     },
   },

docs/content/Schema/Advanced/Code-Reusability-Extending-Cubes.mdx

@@ -41,7 +41,7 @@ cube(`BaseEvents`, {
 
   joins: {
     Users: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.user_id = ${Users.id}`,
     },
   },

docs/content/Schema/Advanced/Polymorphic-Cubes.mdx

@@ -89,11 +89,11 @@ cube(`Lessons`, {
 
   joins: {
     Students: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.student_id = ${Students.id}`,
     },
     Teachers: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.teacher_id = ${Teachers.id}`,
     },
   },

docs/content/Schema/Fundamentals/Additional-Concepts.mdx

@@ -34,12 +34,12 @@ cube(`Orders`, {
 
   joins: {
     Users: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.user_id = ${Users.id}`,
     },
 
     Products: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       sql: `${CUBE}.product_id = ${Products.id}`,
     },
   },
@@ -76,10 +76,10 @@ cubes:
 
     joins:
       - name: Users
-        relationship: belongs_to
+        relationship: many_to_one
         sql: "{CUBE}.user_id = {Users}.id"
       - name: Products
-        relationship: belongs_to
+        relationship: many_to_one
         sql: "{CUBE}.product_id = {Products}.id"
 
     measures:
@@ -175,7 +175,7 @@ cube(`SalesManagers`, {
 
   joins: {
     Deals: {
-      relationship: `hasMany`,
+      relationship: `one_to_many`,
       sql: `${CUBE}.id = ${Deals.salesManagerId}`,
     },
   },
@@ -218,7 +218,7 @@ cubes:
 
     joins:
       - name: Deals
-        relationship: has_many
+        relationship: one_to_many
         sql: "{SalesManagers}.id = {Deals}.sales_manager_id"
 
     measures:

docs/content/Schema/Fundamentals/Concepts.mdx

@@ -331,7 +331,7 @@ cube('Orders', {
 
   joins: {
     LineItems: {
-      relationship: `belongsTo`,
+      relationship: `many_to_one`,
       // Here we use the `CUBE` global to refer to the current cube,
       // so the following is equivalent to `Orders.id = LineItems.order_id`
       sql: `${CUBE}.id = ${LineItems.order_id}`,
@@ -348,19 +348,13 @@ cubes:
         # Here we use the `CUBE` global to refer to the current cube,
         # so the following is equivalent to `Orders.id = LineItems.order_id`
         sql: "{CUBE}.id = {LineItems.order_id}"
-        relationship: belongs_to
+        relationship: many_to_one
 ```
 
 </CodeTabs>
 
-There are three kinds of join relationships:
-
-- `belongsTo`/`belongs_to`
-- `hasOne`/`has_one`
-- `hasMany`/`has_many`
-
-More information can be found in the [Joins reference
-documentation][ref-schema-ref-joins-types].
+There are the three [types of join relationships][ref-schema-ref-joins-types]:
+`one_to_one`, `one_to_many`, and `many_to_one`.
 
 ## Segments