Part 3

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

@@ -110,57 +110,32 @@ It will be translated into a field called `last_name` (notice the underscore), o
   </TabItem>
 
   <TabItem value="bigquery" label="BigQuery">
-    <Tabs groupId="biquery-loader-version" queryString lazy>
-        <TabItem value="v2" label="Version 2.x" default>
+     <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` |
 
-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">
 
 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)).
+
+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` |
+
+   </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.)_
 
@@ -170,13 +145,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).
@@ -204,8 +172,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">