Eager/early serialize of components to arrow in Rust and C++ #7245
Labels
🌊 C++ API
C/C++ API specific
💬 discussion
🪵 Log & send APIs
Affects the user-facing API for all languages
🦀 Rust API
Rust logging API
As we'll soon introduce tagged components and simple multi-datatype components, it gets harder and harder to represent Archetypes (and concrete ComponentBatches) as collection of concrete types.
Let's take the example of a generalized
rotation
component/archetype field which may be represented by various datatypes: we no longer can store concrete types on an archetype and have to type-earse them right away instead.Note that this way C++ and Rust get much closer to the Python SDK in this regard.
This fits very well into our desire to get rid of concrete component types in the SDK languages which today almost always take the form of
struct ComponentType(pub datatypes::TheDataType)
together with myriad of constructors, trait impls and utilities. I.e. a lot of forwarding code.Eager serialization allows us to implement component semantics on archetypes instead with concrete construction methods. E.g.
with_quaternion
andwith_axis_angle
would both populate the multi-datatyperotation
component which gets tagged appropriately.When logging raw component batches/columns this would become more explicit as you're expected to supply a datatype array/collection together with the appropriate component tag (which will still be provided by the SDK, but more in registry fashion rather a
class
/struct
per component). This follows the exact same mechanism of how an archetype construct its internalComponentBatches
.A drawback of this approach is that most accesses of archetypes requires deserialization back into the source datatypes which can be cumbersome in some cases. However, this is what we expect to do when a user reads back data from the store, so this is something that may soon become common-place anyways.
Another nice side effect is that the "ephemeral
rerun::Collection
hazard" goes away as we'd no longer store pointers to user data, making the API a lot safer to use. (rerun::Collection
becomes a pure pass-through type as it should be)rerun::Collection
borrows data too eagerly, making it very easy to cause segfaults & read of invalid data #7081This ticket is a meetup discussion outcome of @jleibs and @Wumpf with some additional input by @emilk
Advantages
f32
orf64
(see https://github.com/rerun-io/rerun/blob/main/design/component_datatypes.md)Related
The text was updated successfully, but these errors were encountered: