Introduce Lens as a concept for semantic mapping of arbitrary data
#11394
Conversation
|
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
|
Web viewer built successfully.
Note: This comment is updated whenever you push a commit. |
There was a problem hiding this comment.
Pull Request Overview
This PR introduces the concept of "Lenses" as an experimental feature for semantic mapping and transformation of arbitrary data in Rerun. Lenses provide a way to re-interpret and manipulate component columns, which is particularly useful for attaching Rerun semantics to arbitrary Arrow components when loading external data formats like MCAP files.
Key changes:
- New
Lensstruct that defines input-to-output transformations for component data LensesSinkthat wraps existing sinks and applies lens transformations before forwarding data- Various transformation operations (
Op) including field access, type casting, and custom functions
Reviewed Changes
Copilot reviewed 11 out of 12 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| examples/rust/lenses/src/main.rs | Complete example demonstrating lens usage with flag transformations, text mapping, and struct destructuring |
| examples/rust/lenses/README.md | Documentation for the lenses example |
| examples/rust/lenses/Cargo.toml | Cargo configuration for the lenses example package |
| crates/top/re_sdk/src/lib.rs | Adds public module declaration for the experimental lenses feature |
| crates/top/re_sdk/src/lenses.rs | Core implementation of the lenses system including sink, operations, and builder patterns |
| Multiple snapshot files | Test snapshots for various lens transformation scenarios |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| // This means we drop chunks that belong to the same entity but don't have the component. | ||
| let Some((_component_descr, list_array)) = found else { | ||
| return Default::default(); | ||
| }; |
There was a problem hiding this comment.
There's not necessarily anything better we can do here, but flagging this as possibly worrisome.
I think the real question is whether a user (esp if using a Func op) can change the validity of a row from null -> some value. If they can, then input-side concatentation of chunks (which auto-fills missing components with nulls) would lead to different outputs.
If we say any null input row must also correspond to a null output row, then this makes sense as a performance optimization.
There was a problem hiding this comment.
If they can, then input-side concatentation of chunks (which auto-fills missing components with nulls) would lead to different outputs.
Hmm, I don't think I follow. What do you mean be "input-side concatenation of chunks" here? The batcher?
There was a problem hiding this comment.
nice!
Left mostly ~style nits. Only more serious concern I have is how operations are modeled right now, but we've already discussed this and we can take of that later. Modelling of inputs & outputs, ast separation as well as the general premise make a lot of sense to me, great start
| use super::*; | ||
|
|
||
| /// Creates a chunk that contains all sorts of validity, nullability, and empty lists. | ||
| // ┌──────────────┬───────────┐ |
There was a problem hiding this comment.
very helpful, thanks for including these
There was a problem hiding this comment.
Fun fact, Claude does a good job going from these schematics to ArrayBuilders.
) ### Related * Closes RR-2552. * Related to RR-2553. * Related to #11394. * [x] Requires #11458. ### What This changes our `protobuf` reflection code to put the entire message behind a single component to make it easier to extract it from lenses. This also guarantees that each protobuf message is always self-contained.
) ### Related * Closes RR-2552. * Related to RR-2553. * Related to #11394. * [x] Requires #11458. ### What This changes our `protobuf` reflection code to put the entire message behind a single component to make it easier to extract it from lenses. This also guarantees that each protobuf message is always self-contained.
| //! Lenses allow you to extract, transform, and restructure component data. They | ||
| //! are applied to chunks that match the specified entity path filter and contain | ||
| //! the target component. | ||
| //! | ||
| //! See [`lenses::Lens`] for more details and assumptions. One way to make use of lenses is | ||
| //! by using the [`lenses::LensesSink`]. | ||
| pub(crate) mod ast; | ||
| mod error; | ||
| mod op; | ||
| mod sink; | ||
|
|
||
| pub use self::{ | ||
| // We should be careful not to expose to much implementation details here. | ||
| ast::{Lens, LensBuilder, Op}, | ||
| error::Error, | ||
| sink::LensesSink, | ||
| }; |
…#11481) ### Related * Follow up of #11394. * Part of RR-2554. ### What This derives the entity path for the output column from the input column's chunk, unless specified otherwise. This saves a lot of duplicated code, because now multiple input entities can be treated at once using the `EntityPathFilter` of the input column.
Related
-formatting option for redacted values #11383.What
This PR introduces the concept of Lenses as a way to express re-interpretation and manipulation of component columns. This can, for example, be useful to attach Rerun semantics to arbitrary Arrow components that are created when loading MCAP files.
For now, the only way to access the feature is via the
LensesSink, which transforms component columns and then forwards aggregated chunks to the backing sink.Important
Lenses are still a very experimental feature and we expect the API to change a lot in upcoming releases.