techdocsmith commented on a change in pull request #11895:
URL: https://github.com/apache/druid/pull/11895#discussion_r745231231
##########
File path: docs/querying/segmentmetadataquery.md
##########
@@ -87,9 +87,11 @@ The format of the result is:
} ]
```
-Dimension columns will have type `STRING`, `FLOAT`, `DOUBLE`, or `LONG`.
-Metric columns will have type `FLOAT`, `DOUBLE`, or `LONG`, or the name of the
underlying complex type such as `hyperUnique` in case of COMPLEX metric.
-Timestamp column will have type `LONG`.
+All columns will contain a `typeSignature` which is the Druid internal
representation of the type information for this column, is what is show in
[`INFORMATION_SCHEMA.COLUMNS`](../querying/sql.md#columns-table) table in SQL,
and is typically the value used to supply Druid with JSON type information at
query or ingest time. This value will be `STRING`, `FLOAT`, `DOUBLE`, `LONG`,
or `COMPLEX<typeName>` (e.g. `COMPLEX<hyperUnique>`).
+
+Additionally, columns will have a legacy friendly `type` name. This might
match `typeSignature` for some column types (`STRING`, `FLOAT`, `DOUBLE`, or
`LONG`) but for COMPLEX columns will only contain the name of the underlying
complex type such as `hyperUnique`.
+
+The timestamp column will always have `typeSignature` and `type` as `LONG`.
Review comment:
```suggestion
The `typeSignature` and `type` for the timestamp column is always `LONG`.
```
##########
File path: docs/querying/segmentmetadataquery.md
##########
@@ -87,9 +87,11 @@ The format of the result is:
} ]
```
-Dimension columns will have type `STRING`, `FLOAT`, `DOUBLE`, or `LONG`.
-Metric columns will have type `FLOAT`, `DOUBLE`, or `LONG`, or the name of the
underlying complex type such as `hyperUnique` in case of COMPLEX metric.
-Timestamp column will have type `LONG`.
+All columns will contain a `typeSignature` which is the Druid internal
representation of the type information for this column, is what is show in
[`INFORMATION_SCHEMA.COLUMNS`](../querying/sql.md#columns-table) table in SQL,
and is typically the value used to supply Druid with JSON type information at
query or ingest time. This value will be `STRING`, `FLOAT`, `DOUBLE`, `LONG`,
or `COMPLEX<typeName>` (e.g. `COMPLEX<hyperUnique>`).
Review comment:
```suggestion
All columns contain a `typeSignature` that Druid uses to represent the
column type information internally. The `typeSignature` is typically the same
value used to identify the JSON type information at query or ingest time. One
of: STRING`, `FLOAT`, `DOUBLE`, `LONG`, or `COMPLEX<typeName>`, e.g.
`COMPLEX<hyperUnique>`.
```
##########
File path: docs/querying/segmentmetadataquery.md
##########
@@ -87,9 +87,11 @@ The format of the result is:
} ]
```
-Dimension columns will have type `STRING`, `FLOAT`, `DOUBLE`, or `LONG`.
-Metric columns will have type `FLOAT`, `DOUBLE`, or `LONG`, or the name of the
underlying complex type such as `hyperUnique` in case of COMPLEX metric.
-Timestamp column will have type `LONG`.
+All columns will contain a `typeSignature` which is the Druid internal
representation of the type information for this column, is what is show in
[`INFORMATION_SCHEMA.COLUMNS`](../querying/sql.md#columns-table) table in SQL,
and is typically the value used to supply Druid with JSON type information at
query or ingest time. This value will be `STRING`, `FLOAT`, `DOUBLE`, `LONG`,
or `COMPLEX<typeName>` (e.g. `COMPLEX<hyperUnique>`).
+
+Additionally, columns will have a legacy friendly `type` name. This might
match `typeSignature` for some column types (`STRING`, `FLOAT`, `DOUBLE`, or
`LONG`) but for COMPLEX columns will only contain the name of the underlying
complex type such as `hyperUnique`.
Review comment:
```suggestion
Druid retains the legacy friendly `type` name. For some column types, the
value may match the `typeSignature` (`STRING`, `FLOAT`, `DOUBLE`, or `LONG`).
For `COMPLEX` columns, the `type` only contains the name of the underlying
complex type such as `hyperUnique`.
New applications should use `typeSignature`, not `type`.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
