Repository navigation
GH-3877: Add FINITE_VECTOR logical type support - #3876
divjotarora wants to merge 18 commits into
Conversation
Fokko
left a comment
There was a problem hiding this comment.
The biggest issue is around the validation. It feels to me that a lot of visitor that are meant to do other things, are now also validating if it is a valid FINITE_VECTOR. I left some other comments as well. Let me know what you think
There was a problem hiding this comment.
Eventually, these should go in https://github.com/apache/parquet-testing/
There was a problem hiding this comment.
Yes, that's definitely the goal here
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Fokko
left a comment
There was a problem hiding this comment.
Thanks @divjotarora for iterating on this, I think we're getting close 👍 Now, my main concern is the performance penalty that we're having because of the validation.
|
Another thing, I think we don't need to collect that much statistics for the vector:
We can also do this in a separate PR |
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Rationale for this change
The FINITE_VECTOR proposal defines fixed-size vectors of non-null, finite elements on canonical LIST storage, so applications can express vector semantics while retaining existing Parquet storage and interoperability. This change brings parquet-java support in line with the proposal.
What changes are included in this PR?
Adds FINITE_VECTOR schema annotations and mandatory write validation, validates stored levels and elements during reads, and preserves LIST interoperability across existing model readers.
Are these changes tested?
The affected Maven suites for FINITE_VECTOR schemas, writing, reading, adapters, and filtered reads passed, and Spotless passed for all touched modules.
Closes #3877