Skip to content

Commit

Permalink
Part 3
Browse files Browse the repository at this point in the history
  • Loading branch information
pondzix committed May 10, 2024
1 parent 647e935 commit 8f27c18
Showing 1 changed file with 10 additions and 48 deletions.
58 changes: 10 additions & 48 deletions docs/storing-querying/schemas-in-warehouse/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -112,55 +112,26 @@ It will be translated into a field called `last_name` (notice the underscore), o
<TabItem value="bigquery" label="BigQuery">
<Tabs groupId="biquery-loader-version" queryString lazy>
<TabItem value="v2" label="Version 2.x" default>

Each type of self-describing event and each type of entity get their own dedicated columns in the `events` table. The name of such a column is composed of the schema vendor, schema name and major schema version (more on versioning [later](#versioning)).

The column name is prefixed by `unstruct_event_` for self-describing events, and by `contexts_` for entities. _(In case you were wondering, those are the legacy terms for self-describing events and entities, respectively.)_

:::note

All characters are converted to lowercase and all symbols (like `.`) are replaced with an underscore.

:::

Examples:

| Kind | Schema | Resulting column |
|---|---|---|
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1` |
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1` |
</TabItem>
<TabItem value="v1" label="Version 1.x">
Each type of self-describing event and each type of entity get their own dedicated columns in the `events` table. The name of such a column is composed of the schema vendor, schema name and full schema version (more on versioning [later](#versioning)).

For self-describing events, the column will be of a `RECORD` type, while for entities the type will be `REPEATED RECORD` (because an event can have more than one entity attached).

Inside the record, there will be fields corresponding to the fields in the schema. Their types are determined according to the logic described [below](#types).

:::note

The name of each record field is the name of the schema field converted to snake case.

:::

:::caution

If an event or entity includes fields not defined in the schema, those fields will not be stored in the warehouse.

:::

For example, suppose you have the following field in the schema:

```json
"lastName": {
"type": "string",
"maxLength": 100
}
```

It will be translated into a field called `last_name` (notice the underscore), of type `STRING`.

</TabItem>
<TabItem value="v1" label="Version 1.x">
Examples:

Each type of self-describing event and each type of entity get their own dedicated columns in the `events` table. The name of such a column is composed of the schema vendor, schema name and full schema version (more on versioning [later](#versioning)).
| Kind | Schema | Resulting column |
|---|---|---|
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1_0_0` |
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1_0_0` |
</TabItem>
</Tabs>

The column name is prefixed by `unstruct_event_` for self-describing events, and by `contexts_` for entities. _(In case you were wondering, those are the legacy terms for self-describing events and entities, respectively.)_

Expand All @@ -170,13 +141,6 @@ All characters are converted to lowercase and all symbols (like `.`) are replace

:::

Examples:

| Kind | Schema | Resulting column |
|---|---|---|
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1_0_0` |
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1_0_0` |

For self-describing events, the column will be of a `RECORD` type, while for entities the type will be `REPEATED RECORD` (because an event can have more than one entity attached).

Inside the record, there will be fields corresponding to the fields in the schema. Their types are determined according to the logic described [below](#types).
Expand Down Expand Up @@ -204,8 +168,6 @@ For example, suppose you have the following field in the schema:

It will be translated into a field called `last_name` (notice the underscore), of type `STRING`.

</TabItem>
</Tabs>
</TabItem>

<TabItem value="snowflake" label="Snowflake">
Expand Down

0 comments on commit 8f27c18

Please sign in to comment.