You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)).
117
116
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.
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)).
132
126
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
-
<TabItemvalue="v1"label="Version 1.x">
127
+
Examples:
162
128
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)).
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.)_
166
137
@@ -170,13 +141,6 @@ All characters are converted to lowercase and all symbols (like `.`) are replace
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).
181
145
182
146
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:
204
168
205
169
It will be translated into a field called `last_name` (notice the underscore), of type `STRING`.
0 commit comments