CTTY commented on code in PR #585: URL: https://github.com/apache/parquet-format/pull/585#discussion_r3430869570
########## LogicalTypes.md: ########## @@ -635,7 +635,76 @@ The type has two type parameters: The sort order used for `GEOGRAPHY` is undefined. When writing data, no min/max statistics should be saved for this type and if such non-compliant statistics -are found during reading, they must be ignored. +are found during reading, they must be ignored. + +### FILE + +`FILE` annotates a group that represents a reference to an external file, along with +the minimum metadata required to read it. It is intended for use cases such as +storing file inventories, manifests, and unstructured data references (e.g., images +or audio files stored in object storage). + +The annotated group must contain the following fields, identified by name. Field IDs +may also be used for projection: + +| Field | Type | Required | +|----------|--------|----------| +| `path` | STRING | Yes | +| `size` | INT64 | No | +| `offset` | INT64 | No | +| `etag` | STRING | No | Review Comment: I'm neutral on whether the Parquet spec should stay minimal or include convenient metadata (content type, metadata map etc.) for common use cases But if we are leaning toward keeping the spec simple, I don't think `etag` should be part of the spec either. `etag` feels more like storage specific metadata than a portable field with consistent semantics across storage systems Would be happy to hear more thoughts on this! -- 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]
