-
Notifications
You must be signed in to change notification settings - Fork 108
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
errors: replace RowsParseError
and narrow the return types after deserialization refactor
#1117
Conversation
See the following report for details: cargo semver-checks output
|
1d5ce8f
to
22b6c36
Compare
22b6c36
to
74aea94
Compare
Rebased on |
74aea94
to
bd79e23
Compare
Apart from nits and comments about the last commit, looks good! |
bd79e23
to
6861167
Compare
Rebased on |
2174378
to
6eaabf2
Compare
v2: Addressed @wprzytula comments. Dropped the last commit that introduces |
6eaabf2
to
9b95760
Compare
v2.1: adjusted book to new |
9b95760
to
2ac12fe
Compare
v2.2: Adjusted book again.. |
2ac12fe
to
654a273
Compare
Let me quickly rebase on main before merge. There are no conflicts with #1124, but I think the code won't compile (since there is an additional variant to |
Please check. I thought Github runs CI on generated merge commit, so if it didn't compile with current main then CI would fail. Is that not the case? |
Previously, the `ResultMetadataParseError` error type was common for both Result and Prepared metadata. It does not make much sense, though. Obviously, some of the error variants are shared between these two types, but not all of them.
An error that occurred during initial deserialization of `RESULT:Rows` response. Since the deserialization of rows is lazy, we initially only need to deserialize: - result metadata flags - column count (result metadata) - paging state response We ultimately want to get rid of current `RowsParseError` since its usage is abused in a lot of places throughout the scylla crate. We start by narrowing the return type of `deser_rows()` function.
I checked (locally). It does not compile if I rebase without any additional changes. |
An error returned by `QueryResult::into_legacy_result()`. Previously, the `QueryResult::into_legacy_result()` would return `RowsParseError`. Note that `RowsParseError` is (for now) included in new error type. This is because `RawMetadataAndRawRows::deserialize_metadata()` still returns `RowsParseError`. This will be adjusted in following commit once we introduce a new error type for `deserialize_metadata` method.
This could only happen if there is a serious bug in the driver. `deser_col_specs_generic` takes `column_count` as argument and deserializes the col specs `column_count` times in a loop. Thus, this check does not make sense.
…metadata Adjusted the error returned by `RawMetadataAndRawRows::deserialize_metadata()`. Again, to narrow the return error type of following methods: - RawMetadataAndRawRows::deserialize_metadata() - QueryResult::into_rows_result() Adjusted the callers of `QueryResult::into_rows_result` in topology.rs and session.rs and added corresponding variants for `TracingProtocolError` and `SchemaVersionFetchError` Temporarily, we need to introduce a corresponding variant to `QueryError` and `NewSessionError`. This is because internal API makes use of `into_rows_result()` in multiple places. The callers will be adjusted later in this PR, allowing us to remove the variant from `Query/NSError`.
We will re-introduce `NewRowError` as an error type returned by current async iterator API.
Weird |
These are errors returned by async iterator API. Ultimately, we want them to be independent types returned by the public API. However, as of now, NextRowError needs to be wrapped in QueryError - to address that, further changes to iter API need to applied. These, however, are not in a scope of this PR. This partial change of iter API is introduced because we want to get rid of RowsParseError dependency in this module.
It's not used anymore after adjustments to iter API. It was introduced temporarily earlier, and can now be safely removed.
So we do not depend on RowsParseError anymore, new variant is introduced that represents a row deserialization failure.
Instead of returning Result<Option<_>, _>, we will simply return a Result. IntoRowsResultError is introduced specifically for this method. Adjusted all of usages of this API. Most of the changes were simply to replace `unwrap().unwrap()` to single `unwrap()`. There are 4 places that require more focus during review: - print_result() method in `cql-sh.rs` example. - changes to SchemaVersionFetchError (and corresponding code in connection.rs) - changes to TracingProtocolError (and corresponding code in session.rs) - adjustment to `scylla_supports_tablets` in test_utils.rs
Co-authored-by: Karol Baryła <[email protected]>
9e9b55d
to
2054163
Compare
Rebased on main (running clippy checks on each commit during rebase). Adjusted the |
Motivation
After deserialization refactor, the
RowsParseError
was widely abused in multiple places, namely:deser_rows()
- initial deserialization of RESULT:Rows responseQueryResult::into_rows_result()
- lazy deserialization of metadataQueryResult::into_legacy_result()
- lazy metadata deserialization, rows deserialization etc.Typecheck/DeserializationError
s toQueryError
- widely abused in iterator APIThis PR fixes that by narrowing the return types of functions originally depending on
RowsParseError
. TheRowsParseError
is removed at the end of this PR.QueryResult::into_rows_result()
return typeThe last two commits adjust the API of
QueryResult
:QueryResult::into_rows_result()
toResult<_, IntoRowsResultError>
. I believe that this API is cleaner than returningOption<Result<...>>
.QueryResult::into_rows_result_with_recovery()
- it does the same asinto_rows_result()
, but recoversself
in case error occurred.Pre-review checklist
./docs/source/
.Fixes:
annotations to PR description.