-
Notifications
You must be signed in to change notification settings - Fork 539
Release 0.23.4: Fix migration of old 0.22 rrd files #10350
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nice, how subtle!
debug_assert_eq!(new_field.data_type(), column.data_type()); | ||
|
||
let mut metadata = old_field.metadata().clone(); | ||
metadata.extend(new_field.metadata().clone()); // overwrite old with new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that work in a setting where we change keys as part of our migration? Because that currently happens on main
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would, if we would call rewire_tagged_components
at the top of SorbetBatch::try_from_record_batch
… unfortunately we call it only in ChunkBatch::try_from
, which I think is a separate bug (we should always rewire tagged components)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll make sure this is correct when I cherry-pick the commit into main
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@emilk
This PR needs to be based off of release-0.23.4-alpha.2
😬 it contains some important changes to the build process, but it was never fully released as 0.23.4
I think those changes can also just be cherry-picked in case you don't want to rebase
https://github.com/rerun-io/rerun/tree/release-0.23.4-alpha.2
Good catch - I'll rebase |
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
our docker container only contains `pip3`
arrow-devel \ | ||
make automake gcc gcc-c++ kernel-devel \ | ||
cmake \ | ||
curl \ | ||
git \ | ||
git-lfs \ | ||
libatk-bridge2.0 \ | ||
libfontconfig1-dev \ | ||
libfreetype6-dev \ | ||
libglib2.0-dev \ | ||
libgtk-3-dev \ | ||
libssl-dev \ | ||
libxcb-render0-dev \ | ||
libxcb-shape0-dev \ | ||
libxcb-xfixes0-dev \ | ||
libxkbcommon-dev \ | ||
lsb-release \ | ||
atk at-spi2-atk \ | ||
fontconfig-devel \ | ||
freetype-devel \ | ||
glib2-devel \ | ||
gtk3-devel \ | ||
openssl-devel \ | ||
xcb-util-renderutil-devel \ | ||
xcb-util-devel \ | ||
xcb-util-wm-devel \ | ||
libxkbcommon-devel \ | ||
python3-pip \ | ||
software-properties-common \ | ||
sudo; \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it would be easier to merge changes to this list if it was sorted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also a bit weird that some things are grouped (atk, make/automake) and others not (xcb) 🤔
Version 0.23.4-rc.2 published successfully.
|
Version 0.23.4 published successfully.
|
Related
What
NOTE! This is a 0.23.4 release branch, as I want to get these fixes out ASAP.
Problem 1: sorbet meta key name confusion
At some point we renamed the keys of our meta-data, and forgot to update our code:
rerun.archetype
vsrerun.archetype_name
rerun.archetype_field
vsrerun.archetype_field_name
Problem 2: not writing new meta keys on migrate
Our migration code erroneously would keep the old metadata of all our fields.
The new code in this PR not only fixes this, but also retains all non-rerun metadata, because it's the right thing to do.
TODO
main
main
main