rdblue commented on code in PR #9717:
URL: https://github.com/apache/iceberg/pull/9717#discussion_r1501928527
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3324,6 +3348,217 @@ components:
type: integer
format: int64
+ BooleanTypeValue:
+ type: boolean
+ example: true
+
+ IntegerTypeValue:
+ type: integer
+ example: 42
+
+ LongTypeValue:
+ type: integer
+ format: int64
+ example: 9223372036854775807
+
+ FloatTypeValue:
+ type: number
+ format: float
+ example: 3.14
+
+ DoubleTypeValue:
+ type: number
+ format: double
+ example: 123.456
+
+ DecimalTypeValue:
+ type: string
+ description:
+ "Decimal type values are serialized as strings. Decimals with a
positive scale serialize as numeric plain
+ text, while decimals with a negative scale use scientific notation and
the exponent will be equal to
+ the negated scale"
+ example:
+ positiveScale: "123.4500"
+ zeroScale: "2"
+ negativeScale: "2E+20"
+
+ StringTypeValue:
+ type: string
+ example: "hello"
+
+ UUIDTypeValue:
+ type: string
+ format: uuid
+ description:
+ "UUID type values are serialized as a lowercase string"
+ example: "eb26bdb1-a1d8-4aa6-990e-da940875492c"
+
+ DateTypeValue:
+ type: string
+ format: date
+ description:
+ "Date type values follow the `YYYY-MM-DD` ISO-8601 standard date
format"
+ example: "2007-12-03"
+
+ TimeTypeValue:
+ type: string
+ description:
+ "Time type values follow the `HH:MM[:SS[.sssssssss]]` ISO-8601 format
with microsecond precision"
+ example: "22:31:08.123456"
+
+ TimestampTypeValue:
+ type: string
+ description:
+ "Timestamp type values follow the
'YYYY-MM-DDTHH:MM[:SS[.sssssssss]][+00:00]' ISO-8601 format with microsecond
+ precision. Timestamps that adjust to UTC include a `+00:00` offset.
Without this offset, the format implies
+ local time"
+ example:
+ withoutTimezone: "2007-12-03T10:15:30"
+ withTimezone: "2007-12-03T10:15:30+00:00"
+ withFractionalSeconds: "2007-03-25T12:34:56.123456"
+
+ FixedTypeValue:
+ type: string
+ description:
+ "Fixed length type values are stored and serialized as a hexadecimal
string preserving the fixed length"
+ example: "000102ff"
+
+ BinaryTypeValue:
+ type: string
+ description:
+ "Binary type values are stored and serialized as a hexadecimal string"
+ example: "000102ff"
+
+ MapTypeValue:
+ type: object
+ description:
+ "A map structure serialized with keys and values arrays that maintain
type"
+ properties:
+ keys:
+ type: array
+ items:
+ $ref: '#/components/schemas/TypeValue'
+ values:
+ type: array
+ items:
+ $ref: '#/components/schemas/TypeValue'
+ example:
+ {
+ keys: [ 1, 2 ],
+ values: [ "foo", "bar" ]
+ }
+
+ StructTypeValue:
Review Comment:
@jackye1995, @geruh, here's a bit more about what I was thinking:
I was trying to say that we should use a list that is in the order of the
fields produced by the partition spec. The content file has a partition spec ID
and that partition spec produces an output type. I would make this a list where
each element corresponds to a field in the output struct type.
The reason why single-value serialization uses a JSON object with field ID
keys is that when it is used to serialize a default value for a struct type, we
want to avoid mistakes. For instance, that allows us to leave the default value
unchanged when a struct's fields are reordered because the field defaults are
tracked by field ID. Otherwise it would be easy to corrupt a default value by
forgetting to rewrite it in certain schema evolution cases (like field
reordering).
Here, we know that that the partition spec and partition tuple are fixed
when the content file is written. That schema won't evolve so I'd prefer to
keep it simple and put the fields in a list.
I could be convinced otherwise, but it seems like avoiding a complicated
structure is a good thing.
--
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]
