feat(source): support Avro Union type #17485
+1,161
−56
Merged
Task list completed / task-list-completed
Started
2024-07-09 11:13:18
ago
3 / 10 tasks completed
7 tasks still to be completed
Details
Required Tasks
Task | Status |
---|---|
record with/without namespace | Completed |
add an e2e test to demonstrate the usage & for documentation | Completed |
I have written necessary rustdoc comments | Incomplete |
I have added necessary unit tests and integration tests | Incomplete |
I have added test labels as necessary. See details. | Incomplete |
I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934). | Incomplete |
My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future). | Incomplete |
All checks passed in ./risedev check (or alias, ./risedev c ) |
Incomplete |
My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details) | Incomplete |
My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users) | Completed |
#17485 👈 | Incomplete |
#17434 | Incomplete |
main |
Incomplete |
There seem to be no obvious problems of the decision. It might not be always the "best" way in all situations, but also not too bad (at most 1 or 2 operations away?). | Incomplete |
These usages are common, so "I would be unwilling to say we support it (if these cases not supported)". (Well this might be arguable, since why few users have requested union/map type before? 🤣) | Incomplete |
Very few additional workload is required. | Incomplete |
there's no serious drawbacks we can come up with | Incomplete |
the decision is reversible | Incomplete |
The invalid schema: ["int", {"type":"int", "logicalType": "date"}] . I guess @fuyufjh is talking about allowing it, because we want to be tolerate. This point makes some sense (like allowing out-of-range JSON numbers?), but currently Rust Avro lib will reject it. |
Incomplete |
Which field name to use for logical types (logical or actual). IMO this is kind of arbitrary decision. | Incomplete |
When physical type is named, use physical name ; else use logical type |
Incomplete |
To better serve potential users. Since users have limited attention, they may not bother telling us their requirements, but will just silently go away when they meet problems. So we'd better make everything smooth if we can already foresee the requirement. | Incomplete |
(This is actually more important to me), unblock us to do later work. | Incomplete |
Loading