end-to-end arrow-based text entries #654
Conversation
| let bundle = MsgBundle::new( | ||
| MsgId::random(), | ||
| obj_path.clone(), | ||
| time_point, | ||
| [ | ||
| rects.map(|rects| rects.try_into().unwrap()), | ||
| colors.map(|colors| colors.try_into().unwrap()), | ||
| ] | ||
| .into_iter() | ||
| .flatten() | ||
| .collect(), | ||
| ); |
There was a problem hiding this comment.
Note: rewritten this way so that the vector of ComponentBundles passed to MsgBundle::new isn't empty, so that we can craft an array of MsgIds with the appropriate length (i.e. number of instances)!
|
|
||
| #[derive(Debug, clap::Parser)] | ||
| #[clap(author, version, about)] | ||
| struct Args { |
There was a problem hiding this comment.
I'm new to our rust samples. Seems like a little bit too much boiler plate right now that we need to reduce?
Hiding stuff away in a example-only helper library if ofc problematic as well.
There was a problem hiding this comment.
I basically just mirrored the only existing Rust example as I haven't been involved with that SDK effort yet, so right now I just want to leave things in a consistent state for those who are! :)
This is the result of a 4-layer deep PR-ception, I'm just happy everyone made it out alive 😄 |
This PR does the necessary for arrow-based text-views to work end-to-end.
Nothing too exciting/surprising besides these two points:
try_add_arrow_data_msgnow has some extra logic to determine theObjectTypeof an entity based on the components in theMsgBundle.This expands upon @jleibs' hack that was there before, and still is very much a hack.
We need this because text views are completely separate.
TimePointhas been elevated to the rank ofComponent!TimePointis now a component and it is now automatically stored with the rest of an entity's components when inserting a new row.This allows us to easily query for all the timelines of a row without having to maintain yet another custom/dedicated index.We need this because text views list all their different timestamps for every row.I originally implemented it that way because it was the simplest/frictionless way of supporting this use case... but it turned out to actually be pretty elegant, I think.This is currently blocked by a performance issue though.DataStorenow keeps an extra index for keeping track of per-message data (see alsoMsgId-as-a-component #655)To try it:
cargo run -p rerun_sdk --example log_text_entriesjust py-build && RERUN_EXP_ARROW=mixed examples/text_logging/main.pyexamples/text_logging/main.pyinmixedmode:Closes #523
Requires
#653#655