docs: use snake-case property names

Author: hassankhan

docs/content/API-Reference/GraphQL-API.mdx

@@ -207,13 +207,13 @@ query {
 
 ### <--{"id" : "Reference"}--> CubeQueryArgs
 
-| Key          | Schema                                | Description                                                                                                                                      |
-| ------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `where`      | [`RootWhereInput`](#root-where-input) | Represents a SQL `WHERE` clause                                                                                                                  |
-| `limit`      | `Int`                                 | A row limit for your query. The default value is `10000`. The maximum allowed limit is `50000`                                                   |
-| `offset`     | `Int`                                 | The number of initial rows to be skipped for your query. The default value is `0`                                                                |
-| `timezone`   | `String`                              | The timezone to use for the query. The default value is `UTC`                                                                                    |
-| `renewQuery` | `Boolean`                             | If `renewQuery` is set to `true`, Cube will renew all `refreshKey` for queries and query results in the foreground. The default value is `false` |
+| Key          | Schema                                | Description                                                                                                                                          |
+| ------------ | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `where`      | [`RootWhereInput`](#root-where-input) | Represents a SQL `WHERE` clause                                                                                                                      |
+| `limit`      | `Int`                                 | A row limit for your query. The default value is `10000`. The maximum allowed limit is `50000`                                                       |
+| `offset`     | `Int`                                 | The number of initial rows to be skipped for your query. The default value is `0`                                                                    |
+| `timezone`   | `String`                              | The timezone to use for the query. The default value is `UTC`                                                                                        |
+| `renewQuery` | `Boolean`                             | If `renewQuery` is set to `true`, Cube will renew all `refresh_key` for queries and query results in the foreground. The default value is `false` |
 
 ### <--{"id" : "Reference"}--> RootWhereInput
 

docs/content/API-Reference/Query-Format.mdx

@@ -49,16 +49,16 @@ A Query has the following properties:
   [TZ Database Name](https://en.wikipedia.org/wiki/Tz_database) format, e.g.:
   `America/Los_Angeles`. The default value is `UTC`.
 - `renewQuery`: If `renewQuery` is set to `true`, Cube will renew all
-  [`refreshKey`][ref-schema-ref-preaggs-refreshkey] for queries and query
+  [`refresh_key`][ref-schema-ref-preaggs-refreshkey] for queries and query
   results in the foreground. However, if the
-  [`refreshKey`][ref-schema-ref-preaggs-refreshkey] (or
-  [`refreshKey.every`][ref-schema-ref-preaggs-refreshkey-every]) doesn't
+  [`refresh_key`][ref-schema-ref-preaggs-refreshkey] (or
+  [`refresh_key.every`][ref-schema-ref-preaggs-refreshkey-every]) doesn't
   indicate that there's a need for an update this setting has no effect. The
   default value is `false`.
   > **NOTE**: Cube provides only eventual consistency guarantee. Using a small
-  > [`refreshKey.every`][ref-schema-ref-preaggs-refreshkey-every] value together
-  > with `renewQuery` to achieve immediate consistency can lead to endless
-  > refresh loops and overall system instability.
+  > [`refresh_key.every`][ref-schema-ref-preaggs-refreshkey-every] value
+  > together with `renewQuery` to achieve immediate consistency can lead to
+  > endless refresh loops and overall system instability.
 - `ungrouped`: If `ungrouped` is set to `true` no `GROUP BY` statement will be
   added to the query. Instead, the raw results after filtering and joining will
   be returned without grouping. By default `ungrouped` queries require a primary
@@ -206,8 +206,8 @@ The opposite operator of `contains`. It supports multiple values.
 }
 ```
 
-This opertor adds `IS NULL` check to include `NULL` values unless you add `null`
-to `values`. For example:
+This operator adds `IS NULL` check to include `NULL` values unless you add
+`null` to `values`. For example:
 
 ```javascript
 {

docs/content/API-Reference/REST-API.mdx

@@ -44,7 +44,7 @@ If the request takes too long to be processed, Cube Backend responds with
 mechanism in Cube is implemented. Clients should continuously retry the same
 query in a loop until they get a successful result. Subsequent calls to the Cube
 endpoints are idempotent and don't lead to scheduling new database queries if
-not required by `refreshKey`. Also, receiving `Continue wait` doesn't mean the
+not required by `refresh_key`. Also, receiving `Continue wait` doesn't mean the
 database query has been canceled, and it's actually still being processed by the
 Cube. Database queries that weren't started and are no longer waited by the
 client's long polling loop will be marked as orphaned and removed from the
@@ -292,7 +292,7 @@ Example response:
           aliasName: 'users.count',
           type: 'number',
           aggType: 'count',
-          drillMembers: ['Users.id', 'Users.city', 'Users.createdAt'],
+          drill_members: ['Users.id', 'Users.city', 'Users.createdAt'],
         },
       ],
       dimensions: [

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

@@ -49,7 +49,7 @@ cube(`Orders`, {
   measures: {
     count: {
       type: `count`,
-      drillMembers: [id, createdAt],
+      drill_members: [id, createdAt],
     },
   },
 
@@ -62,7 +62,7 @@ cube(`Orders`, {
     id: {
       sql: `id`,
       type: `number`,
-      primaryKey: true,
+      primary_key: true,
     },
 
     completedAt: {
@@ -96,7 +96,7 @@ might look something like:
 ```javascript
 cube(`Orders`, {
   // Same content as before, but including the following:
-  preAggregations: {
+  pre_aggregations: {
     orderStatuses: {
       dimensions: [status],
     },
@@ -123,10 +123,10 @@ pre-aggregation definition to the `Orders` schema:
 ```javascript
 cube(`Orders`, {
   // Same content as before, but including the following:
-  preAggregations: {
+  pre_aggregations: {
     ordersByCompletedAt: {
       measures: [count],
-      timeDimension: completedAt,
+      time_dimension: completedAt,
       granularity: `month`,
     },
   },
@@ -167,7 +167,7 @@ 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`
+   - The measures aren't multiplied ([via a `has_many`
      relation][ref-schema-joins-hasmany])
 
 3. If no, then check if
@@ -197,22 +197,22 @@ cube(`LineItems`, {
   joins: {
     Orders: {
       sql: `${CUBE}.order_id = ${Orders.id}`,
-      relationship: `belongsTo`,
+      relationship: `belongs_to`,
     },
   },
 
   measures: {
     count: {
       type: `count`,
-      drillMembers: [id, createdAt],
+      drill_members: [id, createdAt],
     },
   },
 
   dimensions: {
     id: {
       sql: `id`,
       type: `number`,
-      primaryKey: true,
+      primary_key: true,
     },
 
     createdAt: {
@@ -409,7 +409,7 @@ cube(`LineItems`, {
       type: `countDistinctApprox`,
     },
   },
-  preAggregations: {
+  pre_aggregations: {
     myRollup: {
       ...,
       measures: [ CUBE.countDistinctProducts ],
@@ -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 `has_many` relations
 
 - **Leaf measures** are measures that do not reference any other measures in
   their definition
@@ -475,11 +475,11 @@ Some extra considerations for pre-aggregation selection:
   measures and dimensions of any cubes specified in the query are checked to
   find a matching `rollup`.
 
-- `rollup` pre-aggregations **always** have priority over `originalSql`. Thus,
-  if you have both `originalSql` and `rollup` defined, Cube will try to match
-  `rollup` pre-aggregations before trying to match `originalSql`. You can
+- `rollup` pre-aggregations **always** have priority over `original_sql`. Thus,
+  if you have both `original_sql` and `rollup` defined, Cube will try to match
+  `rollup` pre-aggregations before trying to match `original_sql`. You can
   instruct Cube to use the original SQL pre-aggregations by using
-  [`useOriginalSqlPreAggregations`][ref-schema-preaggs-origsql].
+  [`use_original_sql_pre_aggregations`][ref-schema-preaggs-origsql].
 
 [ref-caching-preaggs-cubestore]:
   /caching/using-pre-aggregations#pre-aggregations-storage

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

@@ -38,16 +38,16 @@ data source.
 
 First, you need to create pre-aggregations that will contain your batch data. In
 the following example, we call it **batch**. Please note, it must have a
-`timeDimension` and `partitionGranularity` specified. Cube will use these
+`time_dimension` and `partition_granularity` specified. Cube will use these
 properties to union batch data with freshly-retrieved source data.
 
-You may also control the batch part of your data with the `buildRangeStart` and
-`buildRangeEnd` properties of a pre-aggregation to determine a specific window
+You may also control the batch part of your data with the `build_range_start` and
+`build_range_end` properties of a pre-aggregation to determine a specific window
 for your batched data.
 
 Next, you need to create a lambda pre-aggregation. To do that, create
 pre-aggregation with type `rollupLambda`, specify rollups you would like to use
-with `rollups` property, and finally set `unionWithSourceData: true` to use
+with `rollups` property, and finally set `union_with_source_data: true` to use
 source data as a real-time layer.
 
 Please make sure that the lambda pre-aggregation definition comes first when
@@ -57,22 +57,22 @@ defining your pre-aggregations.
 cube('Users', {
   ...,
 
-  preAggregations: {
+  pre_aggregations: {
     lambda: {
       type: `rollupLambda`,
-      unionWithSourceData: true,
+      union_with_source_data: true,
       rollups: [Users.batch]
     },
     batch: {
       measures: [Users.count],
       dimensions: [Users.name],
-      timeDimension: Users.createdAt,
+      time_dimension: Users.createdAt,
       granularity: `day`,
-      partitionGranularity: `day`,
-      buildRangeStart: {
+      partition_granularity: `day`,
+      build_range_start: {
         sql: `SELECT '2020-01-01'`
       },
-      buildRangeEnd: {
+      build_range_end: {
         sql: `SELECT '2022-05-30'`
       }
     }
@@ -102,7 +102,7 @@ streaming.
 // This cube uses a streaming SQL data source such as ksqlDB
 cube('StreamingUsers', {
   ...,
-  dataSource: 'ksql',
+  data_source: 'ksql',
 
   preAggregations: {
     streaming: {
@@ -119,7 +119,7 @@ cube('StreamingUsers', {
 // This cube uses a data source such as Clickhouse or BigQuery
 cube('Users', {
   ...,
-  preAggregations: {
+  pre_aggregations: {
     batchStreamingLambda: {
       type: `rollupLambda`,
       rollups: [Users.batch, StreamingUsers.streaming]
@@ -128,13 +128,13 @@ cube('Users', {
       type: `rollup`,
       measures: [Users.count],
       dimensions: [Users.name],
-      timeDimension: Users.createdAt,
+      time_dimension: Users.createdAt,
       granularity: `day`,
-      partitionGranularity: `day`,
-      buildRangeStart: {
+      partition_granularity: `day`,
+      build_range_start: {
         sql: `SELECT '2020-01-01'`
       },
-      buildRangeEnd: {
+      build_range_end: {
         sql: `SELECT '2022-05-30'`
       }
     },

docs/content/Caching/Overview.mdx

@@ -68,10 +68,10 @@ cube(`Orders`, {
     },
   },
 
-  preAggregations: {
+  pre_aggregations: {
     amountByCreated: {
       measures: [totalAmount],
-      timeDimension: createdAt,
+      time_dimension: createdAt,
       granularity: `month`,
     },
   },
@@ -87,7 +87,7 @@ Upon receiving an incoming request, Cube first checks the cache using this key.
 If nothing is found in the cache, the query is executed in the database and the
 result set is returned as well as updating the cache.
 
-If an existing value is present in the cache and the `refreshKey` value for the
+If an existing value is present in the cache and the `refresh_key` value for the
 query hasn't changed, the cached value will be returned. Otherwise, an SQL query
 will be executed against either the pre-aggregations storage or the source
 database to populate the cache with the results and return them.
@@ -101,21 +101,21 @@ isn't any different, the cached result is valid and can be returned skipping an
 expensive query, but if there is a difference, the query needs to be re-run and
 its result cached.
 
-To aid with this, Cube defines a `refreshKey` for each cube. [Refresh
+To aid with this, Cube defines a `refresh_key` for each cube. [Refresh
 keys][ref-schema-ref-cube-refresh-key] are evaluated by Cube to assess if the
 data needs to be refreshed.
 
 ```javascript
 cube(`Orders`, {
-  // This refreshKey tells Cube to refresh data every 5 minutes
-  refreshKey: {
+  // This refresh_key tells Cube to refresh data every 5 minutes
+  refresh_key: {
     every: `5 minute`,
   },
 
-  // With this refreshKey Cube will only refresh the data if
+  // With this refresh_key Cube will only refresh the data if
   // the value of previous MAX(created_at) changed
-  // By default Cube will check this refreshKey every 10 seconds
-  refreshKey: {
+  // By default Cube will check this refresh_key every 10 seconds
+  refresh_key: {
     sql: `SELECT MAX(created_at) FROM orders`,
   },
 });
@@ -136,13 +136,13 @@ recommend always enabling background refresh.
 
 ### <--{"id" : "In-memory Cache"}--> Default Refresh Keys
 
-The default values for `refreshKey` are
+The default values for `refresh_key` are
 
 - `every: '2 minute'` for BigQuery, Athena, Snowflake, and Presto.
 - `every: '10 second'` for all other databases.
 
 +You can use a custom SQL query to check if a refresh is required by changing
-the [`refreshKey`][ref-schema-ref-cube-refresh-key] property in a cube's Data
+the [`refresh_key`][ref-schema-ref-cube-refresh-key] property in a cube's Data
 Schema. Often, a `MAX(updated_at_timestamp)` for OLTP data is a viable option,
 or examining a metadata table for whatever system is managing the data to see
 when it last ran.
@@ -161,9 +161,9 @@ wasn't initiated earlier by another client. Only Refresh Key freshness
 guarantees are provided in this case.
 
 For situations like real-time analytics or responding to live user changes to
-underlying data, the `refreshKey` query cache can prevent fresh data from
+underlying data, the `refresh_key` query cache can prevent fresh data from
 showing up immediately. For these situations, the cache can effectively be
-disabled by setting the [`refreshKey.every`][ref-schema-ref-cube-refresh-key]
+disabled by setting the [`refresh_key.every`][ref-schema-ref-cube-refresh-key]
 parameter to something very low, like `1 second`.
 
 ## Inspecting Queries
@@ -174,7 +174,7 @@ Cloud][link-cube-cloud].
 
 [Developer Playground][ref-dev-playground] can be used to inspect a single
 query. To do that, click the "cache" button after executing the query. It will
-show you the information about the `refreshKey` for the query and whether the
+show you the information about the `refresh_key` for the query and whether the
 query uses any pre-aggregations. To inspect multiple queries or list existing
 pre-aggregations, you can use [Cube Cloud][link-cube-cloud].