Skip to content
This repository was archived by the owner on May 17, 2024. It is now read-only.

Conversation

@RoderickJDunn
Copy link
Contributor

@RoderickJDunn RoderickJDunn commented Feb 24, 2023

Changes

  • If min_key + max_key are both passed in as parameters, the query_key_range query is bypassed
  • If only one of min_key or max_key are passed in, query_key_range is called but the min or max is overridden with the user-provided value.

fixes #401

Copy link
Contributor

@erezsh erezsh left a comment

Choose a reason for hiding this comment

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

This is too complicated.

I don't think you need to change anything except for _bisect_and_diff_tables(). And possibly change query_key_range() signature to query_key_range(self, get_min=True, get_max=True). (though always querying both min and max, and discarding the one you don't need, is simpler, and won't affect performance in a meaningful way)

(there would be more code comments, but first I think the approach needs to be simplified)


# Query min/max values
key_ranges = self._threaded_call_as_completed("query_key_range", [table1, table2])
if all([table1.min_key, table1.max_key, table2.min_key, table2.max_key]):
Copy link
Contributor

Choose a reason for hiding this comment

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

You should test for is None, because keys can be 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah true, will fix that

@RoderickJDunn
Copy link
Contributor Author

Ok I'll simplify things :)

):
...

def _resolve_key_range(self, key_range_res, usr_key_range):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

extracted to a function since this logic is needed twice.

@RoderickJDunn
Copy link
Contributor Author

Lmk if this is closer to what you have in mind!

@dlawin
Copy link
Contributor

dlawin commented Jun 8, 2023

Hey @RoderickJDunn, apologies that this PR has been sitting so long. Is this a change you're still interested in making?

@RoderickJDunn
Copy link
Contributor Author

@dlawin I'm using a fork with some additional functionality (including this) and would like to contribute the changes upstream at some point. So I think this can be closed for now, since there doesn't seem to be interest from others in this change. Thanks for checking in!

@dlawin
Copy link
Contributor

dlawin commented Jun 8, 2023

Sounds good @RoderickJDunn, let us know!

@dlawin dlawin closed this Jun 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unexpected behavior using min_key/max_key

4 participants