-
Notifications
You must be signed in to change notification settings - Fork 21
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add multi version support example #133
base: main
Are you sure you want to change the base?
Add multi version support example #133
Conversation
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.
Left a few comments, but LGTM
// the cluster. Thus, we catch it by doing a get version request to establish the connection | ||
// The 3000ms timeout is a guard to avoid waiting forever when the cli cannot talk to any coordinators | ||
loop { | ||
let trx = db.create_trx().expect("could not create transaction"); |
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.
If the first-ever transaction is always failing, I think we can put it before the loop with a expect_err
// when using external clients, it will throw cluster_version_changed for the first time establish the connection to | ||
// the cluster. Thus, we catch it by doing a get version request to establish the connection | ||
// The 3000ms timeout is a guard to avoid waiting forever when the cli cannot talk to any coordinators | ||
loop { |
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.
Can you replace the loop with a db.run
? Is 1039 retryable?
} | ||
break; | ||
} | ||
// write initial value |
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 think we can just do a set/get for the test
@@ -72,7 +72,19 @@ impl FdbApiBuilder { | |||
self.runtime_version, | |||
fdb_sys::FDB_API_VERSION as i32, | |||
) | |||
})?; | |||
}).map_err(|e| { | |||
// 2203: api_version_not_supported |
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.
This is pretty cool 馃憤
Pull Request Test Coverage Report for Build 9033137811Details
馃挍 - Coveralls |
Could you rebase on branch on main? macos's CI was broken because of #138 |
* Gives an explicit error when the target FoundationDB client version is not supported by the locally installed FoundationDB client lib. Signed-off-by: AlexandreBrg <alexandre.burgoni@clever-cloud.com>
* Creates an example which run a transaction with multiple FoundationDB API Client, allowing to support multiple versions. Signed-off-by: AlexandreBrg <alexandre.burgoni@clever-cloud.com>
563eebd
to
d8bf3d2
Compare
Hi 馃憢
This PR brings an example of usage for the multi_version feature of FoundationDB library client. Moreover, I added a small error handling when defining the client API version to use. It will help to better understand that the installed lib version is below required rust client version.