Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Codegen'd Rust/Arrow (de)ser 5: doc, definitions and regression tests…
… for combinatorial affixes (#2546) **Best reviewed on a commit-by-commit basis; in particular the `rerun codegen` commit is nothing but generated code.** This PR documents what we call "affixes", why they're problematic when contributing to the codegen stack and why we need to have regression tests in place for them. Quoting the newly added doc: > ### Understanding the subtleties of affixes > > So-called "affixes" are effects applied to objects defined with the Rerun IDL and that affect > the way these objects behave and interoperate with each other (so, yes, monads. shhh.). > > There are 3 distinct and very common affixes used when working with Rerun's IDL: transparency, > nullability and plurality. > > Broadly, we can describe these affixes as follows: > - Transparency allows for bypassing a single layer of typing (e.g. to "extract" a field out of > a struct). > - Nullability specifies whether a piece of data is allowed to be left unspecified at runtime. > - Plurality specifies whether a piece of data is actually a collection of that same type. > > We say "broadly" here because the way these affixes ultimately affect objects in practice will > actually depend on the kind of object that they are applied to, of which there are 3: archetypes, > components and datatypes. > > Not only that, but objects defined in Rerun's IDL are materialized into 3 distinct environments: > IDL definitions, Arrow datatypes and native code (e.g. Rust & Python). > > These environment have vastly different characteristics, quirks, pitfalls and limitations, > which once again lead to these affixes having different, sometimes surprising behavior > depending on the environment we're interested in. > Also keep in mind that Flatbuffers and native code are generally designed around arrays of > structures, while Arrow is all about structures of arrays! > > All in all, these interactions between affixes, object kinds and environments lead to a > combinatorial explosion of edge cases that can be very confusing when it comes to (de)serialization > code, and even API design. > > When in doubt, check out the `rerun.testing.archetypes.AffixFuzzer` IDL definitions, generated code and > test suites for definitive answers. At the moment, the test suite merely checks that the native objects that are generated make sense. Serialization roundtrips will be added in a couple PRs. It also only focuses on the Rust backend, as I'm still unsure what complex, deeply nested objects are gonna look like in the Python backend (need to work on #2390 first to get a feel for it). Also note that, for now, test-archetypes are mixed in with all other user-facing archetypes, which is not ideal. We'll work towards something better as the dust settle, as for now the overall organization of things is still a moving target (#2537). --- - #2484 - #2485 - #2487 - #2545 - #2546 - #2549 - #2554 - #2570 - #2571 --- <!-- This line will get updated when the PR build summary job finishes. --> PR Build Summary: https://build.rerun.io/pr/2487 <!-- pr-link-docs:start --> Docs preview: https://rerun.io/preview/46068dd/docs Examples preview: https://rerun.io/preview/46068dd/examples <!-- pr-link-docs:end -->
- Loading branch information