-
Notifications
You must be signed in to change notification settings - Fork 23
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
Handle failed changes properly #269
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.
pub fn process_complete_version( | ||
agent: Agent, | ||
tx: &Transaction, | ||
sp: &Savepoint, |
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.
Little bit of fun knowledge: Both Transaction
and Savepoint
implement Deref<Target=Connection>
, so we could use &Connection
here as a type and it'd "just work" properly, but it is nicer to have it explicit like you did there. This makes it harder to send the wrong type.
.query_row([], |row| row.get::<_, String>(0)); | ||
assert!(res.is_err()); | ||
assert_eq!(res, Err(rusqlite::Error::QueryReturnedNoRows)); | ||
|
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 also check that the db_version
inserted and the ones Corrosion associated with its internal version are correct? Possibly by trying to apply the bad change first.
I vaguely recall we do some db version arithmetics and we might need to subtract when we're rolling back a savepoint.
This enables us to process other vesions in process_multiple_changes even if one of them fails
bea5135
to
68daa16
Compare
This pull request adds the following changes:
process_multiple_changes
so if one version fails we can continue with the others.