Apps can create custom tables to store specific data.
Usage
In your app manifest.json, you can define new tables adding a app_tables property like this:
...
"app_tables": [
{
"name": "appx_myapp_table_1",
"description": "Example of extra table",
"shard_key": ["id"],
"unique_key": ["id"],
"sort_key": ["created_at"],
"columns": [
{
"name": "id",
"type": "varchar"
},
{
"name": "external_id",
"type": "varchar"
},
{
"name": "created_at",
"type": "datetime"
},
{
"name": "user_id",
"type": "varchar"
},
{
"name": "merged_from_user_id",
"type": "varchar"
},
{
"name": "fields_timestamp",
"type": "json"
},
{
"name": "db_created_at",
"type": "timestamp"
},
{
"name": "db_updated_at",
"type": "timestamp"
},
{
"name": "column_varchar",
"type": "varchar",
"size": 128,
"description": "Example of varchar column",
"is_required": false
},
{
"name": "column_number",
"type": "number",
"description": "Example of number column",
"is_required": false
},
{
"name": "column_boolean",
"type": "boolean",
"description": "Example of boolean column",
"is_required": false
},
{
"name": "column_datetime",
"type": "datetime",
"description": "Example of datetime column",
"is_required": false
},
{
"name": "column_json",
"type": "json",
"description": "Example of json column",
"is_required": false
}
],
"joins": [
{
"external_table": "appx_myapp_table_2",
"relationship": "one_to_many",
"local_column": "external_id",
"external_column": "table1_external_id"
}
],
"indexes": [
{
"name": "index_column_varchar",
"columns": ["column_varchar"]
}
]
}
]
...
The table columns should follow the Table Column schema.
App tables are removed from the database when the apps are deleted.
Specific columns
Every app table should have the following columns:
...
"columns": [
{
"name": "id",
"type": "varchar"
},
{
"name": "external_id",
"type": "varchar"
},
{
"name": "created_at",
"type": "datetime"
},
{
"name": "fields_timestamp",
"type": "json"
},
{
"name": "db_created_at",
"type": "timestamp"
},
{
"name": "db_updated_at",
"type": "timestamp"
},
...
]
...
The id and external_id columns are used to identify the records.
The external_id is the ID of the record in your external system, and the id is a SHA1 hash of the external_id used by Rimdian.
The created_at column is used to track the creation of the records in your external system.
The fields_timestamp column is used to track the changes in the record fields.
The db_created_at and db_updated_at columns are used to track the creation and update of the records in the database.
User activity
In order to join the table records to the users activity, the user_id & merged_from_user_id columns should be added to the table.
When user profiles are merged, the user_id column is updated with the new user ID, and the merged_from_user_id column is updated with the old user ID.
...
"columns": [
...
{
"name": "user_id",
"type": "varchar",
"size": 64,
"description": "user_id",
"is_required": true,
"hide_in_analytics": true
},
{
"name": "merged_from_user_id",
"type": "varchar",
"size": 64,
"description": "merged_from_user_id",
"is_required": false,
"hide_in_analytics": true
},
...
]
...
Shard key
The shard_key is used to distribute the records across the database shards.
The records are grouped by the shard_key and stored in the same shard.
It should contain at least one column.
If you define a user_id column, it’s recommended to use it as the shard_key. This way the records are stored in the same shard as the user activity.
I.e:
...
"shard_key": ["user_id"],
...
Unique key
The unique_key is used to ensure that the records are unique in the table.
It should contain at least the columns used in the shard_key.
I.e:
...
"unique_key": ["id", "user_id"],
...
Sort key
The sort_key is used to store the records in the database in a specific order.
It should contain at least one column.
If the data is time-based, it’s recommended to use the created_at column as the sort_key. This way the records are stored in the database in the same order as they were created.
I.e:
...
"sort_key": ["created_at"],
...
Joins
By declaring relationships between the app tables and other tables, the Cube.js semantic layer can join the app tables with other tables.
...
"joins": [
{
"external_table": "appx_myapp_table_2",
"relationship": "one_to_many",
"local_column": "external_id",
"external_column": "table1_external_id"
}
]
...
Relationships can be defined as one_to_one, one_to_many or many_to_one. Read more about the Joins directions.
Indexes
You can define indexes to speed up your SQL queries.
Indexes are created as HASH indexes. It means it only works for equality comparisons.
...
"indexes": [
{
"name": "index_column_varchar",
"columns": ["column_varchar"]
}
]
...
