-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[test-adapter] refactor query interpolation and change format for bcs cursors #21150
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
3dfced4
to
03b548d
Compare
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.
Your introduction of parentheses has made me think that that is probably the overall superior syntax -- bcs(@{obj_1_1},2)
and bcs(@{obj_1_1})
instead of bcs:(...)
and bcs_obj:...
-- what do you think?
/// 1. bcs_obj:@{obj_name}: we need to encode the object id and the checkpoint number into the cursor | ||
/// 2. bcs:(@{obj_name},n_0,n_1,...): we need to encode the object id and the following numbers into the cursor | ||
/// 3. cursor contents that does not need bcs encoding: we can just encode the cursor contents directly into base64 | ||
fn interpolate_cursor( |
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.
There may be a simpler and more general way to go about this:
Incorporating the suggestion above, let's say the different kinds of cursor are bcs(ID,N0,N1,...,Nk)
where k >= 0
, or just a plain cursor.
Firstly, say that ID
can be any string we parse as an ObjectID.
- When gathering named variables, we no longer need to treat ObjectIDs specially -- we add them to the list of mappings, using their string representation.
- When interpolating a cursor, we can treat it like other content (no special function for interpolating a cursor) -- the ObjectID gets substituted as a string, and then parsed.
- We get support for passing in literal ObjectIDs.
Similarly, pass highest_checkpoint
as a named variable: bcs(@{obj_x_y},@{highest_checkpoint})
.
We're doing some redundant work (serializing ObjectID and highest checkpoint, and then parsing them), but that is consistent with how variable binding works in the transactional test runner (and it significantly simplifies the implementation).
Finally, you need a function that encodes a given cursor, which can also be simplified now (no more special cases, or implicit behaviour):
fn encode_cursor(&self, cursor: &str) -> anyhow::Result<String> {
let Some(args) = cursor
.strip_prefix("bcs(")
.and_then(|c| c.strip_suffix(")"))
else {
return Ok(Base64::encode(cursor));
};
let mut parts = args.split(",");
let id: ObjectID = parts
.next()
.context("bcs(...) cursors must have at least one argument")?
.trim()
.parse()?;
let mut bytes = bcs::to_bytes(&id)?;
for part in parts {
let n: u64 = part.trim().parse()?;
bytes.extend(bcs::to_bytes(&n)?);
}
Ok(Base64::encode(bytes))
}
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.
Good suggestion and I've implemented it in the modified commit.
03b548d
to
b9e30f1
Compare
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.
Looks great!
Description
This PR refactors the query interpolation part of transactional test adapter and changes the format for bcs cursors:
bcs_obj:
then only an object id is expected and the test adapter will supplement with highest cp sequence number to be encoded together with the object idbcs:
then a tuple of an object id and at least one number is expected. And they will together be encoded.Test plan
modified existing tests
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.