Skip to content
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

docs: migration guide #887

Merged
merged 2 commits into from
Dec 18, 2023
Merged

docs: migration guide #887

merged 2 commits into from
Dec 18, 2023

Conversation

piodul
Copy link
Collaborator

@piodul piodul commented Dec 18, 2023

In 0.11, the serialization traits are reworked and some guidance will be needed to adapt the existing code to the new traits. A document is added which explains the reason behind the changes, potential issues to watch for and tools that should make migration easier.

Additionally, the ValueList and ValueListAdapter helper types are introduced, which are then mentioned in the migration doc.

Pre-review checklist

  • I have split my patch into logically separate commits.
  • All commit messages clearly explain what they change and why.
  • I added relevant tests for new features and bug fixes.
  • All commits compile, pass static checks and pass test.
  • PR description sums up the changes and reasons why they should be introduced.
  • I have provided docstrings for the public items that I want to introduce.
  • I have adjusted the documentation in ./docs/source/.
  • I added appropriate Fixes: annotations to PR description.

Add newtype wrappers that implement `SerializeRow`/`SerializeCql` if the
type wrapped over implements `ValueList`/`Value`. It should be useful
when migrating codebases to the new traits gradually so that objects
from the unchanged code which only implement the old trait can be passed
to the code which was already updated to the new traits.
@piodul piodul force-pushed the migration-guide branch 2 times, most recently from 048363e to db4a121 Compare December 18, 2023 08:39

## Background

When executing a statement through the CQL protocol, values for the bind markers are sent in a serialized, untyped form. In order to implement a safer and more robust interface, drivers can the information returned after preparing a statement to check the type of the data provided by the user against the actual types of the bind markers.
Copy link
Collaborator

Choose a reason for hiding this comment

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

drivers can the information - did you mean can use?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes - thanks, corrected.


If you send simple statements along with non-empty lists of values, the slowdown will be as follows:

- For `Session::query`, the driver will optionally prepare the statement before sending it, incurring an additional round-trip.
Copy link
Collaborator

Choose a reason for hiding this comment

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

optionally? I think driver is always going to do it

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hm, yeah, by optional I meant here that it only happens when there are values for the query, but I agree that it's more natural to omit "optional" given the "If you send simple statements..." sentence.

In 0.11, the serialization traits are reworked and some guidance will be
needed to adapt the existing code to the new traits. Add a document
which explains the reason behind the changes, potential issues to watch
for and tools that should make migration easier.
@Lorak-mmk Lorak-mmk merged commit 187c331 into scylladb:main Dec 18, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants