Skip to content

Commit 8f27c18

Browse files
committed
Part 3
1 parent 647e935 commit 8f27c18

File tree

1 file changed

+10
-48
lines changed
  • docs/storing-querying/schemas-in-warehouse

1 file changed

+10
-48
lines changed

docs/storing-querying/schemas-in-warehouse/index.md

+10-48
Original file line numberDiff line numberDiff line change
@@ -112,55 +112,26 @@ It will be translated into a field called `last_name` (notice the underscore), o
112112
<TabItem value="bigquery" label="BigQuery">
113113
<Tabs groupId="biquery-loader-version" queryString lazy>
114114
<TabItem value="v2" label="Version 2.x" default>
115-
116115
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)).
117116

118-
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.)_
119-
120-
:::note
121-
122-
All characters are converted to lowercase and all symbols (like `.`) are replaced with an underscore.
123-
124-
:::
125-
126117
Examples:
127118

128119
| Kind | Schema | Resulting column |
129120
|---|---|---|
130121
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1` |
131122
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1` |
123+
</TabItem>
124+
<TabItem value="v1" label="Version 1.x">
125+
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)).
132126

133-
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).
134-
135-
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).
136-
137-
:::note
138-
139-
The name of each record field is the name of the schema field converted to snake case.
140-
141-
:::
142-
143-
:::caution
144-
145-
If an event or entity includes fields not defined in the schema, those fields will not be stored in the warehouse.
146-
147-
:::
148-
149-
For example, suppose you have the following field in the schema:
150-
151-
```json
152-
"lastName": {
153-
"type": "string",
154-
"maxLength": 100
155-
}
156-
```
157-
158-
It will be translated into a field called `last_name` (notice the underscore), of type `STRING`.
159-
160-
</TabItem>
161-
<TabItem value="v1" label="Version 1.x">
127+
Examples:
162128

163-
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)).
129+
| Kind | Schema | Resulting column |
130+
|---|---|---|
131+
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1_0_0` |
132+
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1_0_0` |
133+
</TabItem>
134+
</Tabs>
164135

165136
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.)_
166137

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

171142
:::
172143

173-
Examples:
174-
175-
| Kind | Schema | Resulting column |
176-
|---|---|---|
177-
| Self-describing event | `com.example/button_press/jsonschema/1-0-0` | `events.unstruct_event_com_example_button_press_1_0_0` |
178-
| Entity | `com.example/user/jsonschema/1-0-0` | `events.contexts_com_example_user_1_0_0` |
179-
180144
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).
181145

182146
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).
@@ -204,8 +168,6 @@ For example, suppose you have the following field in the schema:
204168

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

207-
</TabItem>
208-
</Tabs>
209171
</TabItem>
210172

211173
<TabItem value="snowflake" label="Snowflake">

0 commit comments

Comments
 (0)