Description
After releasing serialization refactor several users reported use cases that are not well-supported by our new APIs.
The problems come from the need to have specific (non-generic) owned type for query values.
Previously SerializedValues
was such a type. You could use it to serialize values ahead of time and then pass it around as you wish.
After refactor you would need to use types like Vec<Box<dyn SerializeCql>>
or Box<dyn SerializeRow>
, depending on your use case. There are some disadvantages
- Additional allocations.
- Need the values type to be owned - which is a problem if they come from e.g. zero-copy deserialization because you need to clone them.
- If you need specific values to also be dynamic or add them one-by-one, then you need to use something like
Vec<Box<dyn SerializeCql>>
and put that in a box - that's a lot more allocations and indirections.
So in short: migration to new API is possible in every case (I think), but sometimes the performance cost is high.
I propose to introduce new query type (like Query
and PreparedStatement
): BoundStatement
. This is a prepared statement that also stores serialized values.
This would allow users to serialize parameters ahead of time while remaining type-safe and avoiding unnecessary allocations.
My first idea for an API is a a bind(&self, values: impl SerializeRow) -> BoundStatement
method on PreparedStatement
.
We can also think about allowing to bind values one by one. This would complicate the API and implementation and introduce some runtime errors (e.g. if user first binds value by order and then by name), but would be more flexible.
Main problem I see is how to adapt our Session API to this - creating another set of methods, like for Query
and PreparedStatement
seems bloaty.
There are more reasons to work on our Session API (potentially removing Query
with values, bad naming etc), so I think we should discuss Session API changes in #713
Right now probably the most reasonable solution that would allow us to support BoundStatement
is Executable
trait suggested in this issue.
Relevant issues / discussions:
#890
#713
https://scylladb-users.slack.com/archives/C01D7LCL44D/p1708948081839569