Skip to content
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

Use Range<u64> as argument for the RangeQueryHandle::get() #7395

Closed
wants to merge 1 commit into from

Conversation

abey79
Copy link
Member

@abey79 abey79 commented Sep 10, 2024

What

Minor change of API suggested by @emilk: use Range<u64> for the RangeQueryHandle::get(row_range) API.

Checklist

  • I have read and agree to Contributor Guide and the Code of Conduct
  • I've included a screenshot or gif (if applicable)
  • I have tested the web demo (if applicable):
  • The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
  • If applicable, add a new check to the release checklist!
  • If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

To run all checks from main, comment on the PR with @rerun-bot full-check.

@abey79 abey79 added ⛃ re_datastore affects the datastore itself 🚜 refactor Change the code, not the functionality exclude from changelog PRs with this won't show up in CHANGELOG.md labels Sep 10, 2024
@@ -219,7 +220,9 @@ impl RangeQueryHandle<'_> {
/// This is the most performant way to iterate over the dataset.
//
// TODO(cmc): This could be turned into an actual lazy iterator at some point.
pub fn get(&self, offset: u64, mut len: u64) -> Vec<RecordBatch> {
pub fn get(&self, row_range: Range<u64>) -> Vec<RecordBatch> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use a

Suggested change
pub fn get(&self, row_range: Range<u64>) -> Vec<RecordBatch> {
pub fn get(&self, row_range: Range<u64>) -> Vec<RecordBatch> {
debug_assert!(row_range.start <= row_range.end, "Negative range: {row_range}");

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% sure about this one. This is user input (via the SDK), so I think it should be validated a bit less... drastically? Here I opted for (silently) returning an empty dataframe if the range length is <= 0. We probably will have more explicit error handling in the future, but that seemed overkill for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably will have more explicit error handling in the future

Yeah, an error-result would have been my expectation here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, this very API change is what spawned this error condition in the first place. (offset: u64, len: u64) encodes better than Range<u64> the fact that "inverted ranges" are invalid.

With the fact that Range is not Copy and is occasionally annoying, this makes me question this entire PR. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, interesting point.

I actually do prefer the offset/len structure as it is closer to offset / limit that shows up in SQL or other datafusion integrations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Let's scrap this.

@abey79
Copy link
Member Author

abey79 commented Sep 10, 2024

Closing as not really desirable.

@abey79 abey79 closed this Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exclude from changelog PRs with this won't show up in CHANGELOG.md ⛃ re_datastore affects the datastore itself 🚜 refactor Change the code, not the functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants