laskoviymishka commented on code in PR #17822: URL: https://github.com/apache/iceberg/pull/17822#discussion_r4352681105
########## format/spec.md: ########## @@ -693,6 +696,112 @@ Sorting floating-point numbers should produce the following behavior: `-NaN` < ` A data or delete file is associated with a sort order by the sort order's id within [a manifest](#manifests). Therefore, the table must declare all the sort orders for lookup. A table could also be configured with a default sort order id, indicating how the new data should be sorted by default. Writers should use this default sort order to sort the data on write, but are not required to if the default order is prohibitively expensive, as it would be for streaming writes. +### Constraints + +Constraints are added in v4 and are not supported in v3 or earlier. + +A **constraint** declares a condition that a table's live rows are expected to satisfy. Its definition is stored in table metadata. Each snapshot contains the writer-reported status of each constraint that existed when the snapshot was created; see [Constraint Validation](#constraint-validation). + +Three constraint types are defined: + +* `check` -- every row must satisfy a predicate +* `unique` -- the values of a set of fields must be distinct across the rows in which every field in the set is non-null; a row in which any field in the set is null is not compared, so more than one such row may exist +* `primary-key` -- the values of a set of fields must be distinct across all rows and must not be null + +A constraint is stored separately from the table schema and must refer to fields by field ID. Constraints may evolve independently from the schema, being added, modified, or removed. + +#### Constraint Fields + +A constraint consists of the following fields: + +| Requirement | Field name | Type | Description | +|-------------|---------------------------|-----------|-------------| +| _required_ | **`constraint-id`** | `int` | ID of the constraint; unique within the table | +| _required_ | **`type`** | `string` | The constraint type: `check`, `unique`, or `primary-key` | Review Comment: What should a reader or writer do with a constraint whose `type` isn't `check`, `unique` or `primary-key`? As I read [line 720](https://github.com/apache/iceberg/blob/83cb5ef96bcccdab32ff836d6b61c27ed4cfc392/format/spec.md?plain=1#L720), nothing covers other values. For partition transforms, [line 604](https://github.com/apache/iceberg/blob/83cb5ef96bcccdab32ff836d6b61c27ed4cfc392/format/spec.md?plain=1#L604) has readers ignore unknown transforms and writers refuse to commit with them. Should constraints get a similar rule, so engines that predate a new type handle it the same way? -- 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]
