-
Notifications
You must be signed in to change notification settings - Fork 61
Better Debug instances and __repr__ methods.
#891
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
88eee6a to
c2b8a4a
Compare
Python's `SnapshotInfo` now also includes the Manifests info.
c2b8a4a to
2a04921
Compare
| written_at: val.flushed_at, | ||
| message: val.message, | ||
| metadata: val.metadata.into(), | ||
| manifests: val.manifests.into_iter().map(|v| v.into()).collect(), |
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.
Isn't this potentially a really big list? that will now be listed our with ancestry?
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.
Maybe we should have SnapshotInfo.list_manifests() instead?
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.
yes, but, ancestry is very slow anyway, since it fetches each snapshot from object store. Gathering the few manifests cannot add much
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.
Do you think the list of manifests could get very long with split? Don't forget this is only done when you try to print a snapshot, not something you would do a lot, or would expect to be fast.
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.
scratch, my latest about "print". What I should have said is: these objects get populated only by ancestry, which is very slow, and they are mostly used and discarded, I don't imagine gathering a few hundred extra objects will become a problem
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 I understand now. My goal with this was trying to give us a bit more insight to debug, using the lookup_snapshot method. I like the idea of having a dedicated ancestry representation, that could be text in the console, html in a notebook, etc
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.
An updating weather forecast repo might have O(100) manifests in each snapshot, one per array, for example.
But we are not fetching those manifests, only surfacing the data that is already in the snapshot, maybe 30 bytes per manifest or so.
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.
But this definitely has an impact on the repr for snapshots. Do you want me to skip manifests there? we can do that
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.
Yes, I'm only concerned about the repr, because we use it for ancestry right now.
Yes, let's just comment it out from the repr for now.
This will help for my update to test_can_read_old.py
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.
Done in f9baf05
Python's
SnapshotInfonow also includes the Manifests info.