scylladb/scylla-rust-driver

SerializeRow (and maybe SerializeCql) require direct dependency on Scylla while FromRow does not

Jasperav opened this issue · 5 comments

There is an inconsistency when deriving SerializeRow compared to FromRow. This is the generated code:

impl ::scylla::_macro_internal::SerializeRow for AnotherTestTable {

And

impl scylla::_macro_internal::FromRow for AnotherTestTable {

Notice the missing :: in FromRow. The additional :: in SerializeRow forces users to have Scylla as a root dependency (I think). This is a problem for Catalytic users, which re-exports the dependency, making sure users are always using a compatible crate version. I can not compile the code now, even though scylla is just in scope but not available as root dependency.

Can this constraint be lifted and be implemented the same for FromRow? Or maybe there is a workaround which I am not familiar with for Catalytic...

It looks like we made a bit of a mistake with documentation, and the only place documentation for our new proc macros is shown is scylla-cql crate - not scylla crate. We'll make sure to fix that.

Docs for SerializeRow can be found here: https://docs.rs/scylla-cql/latest/scylla_cql/macros/derive.SerializeRow.html

As you can see there, there is crate attribute created exactly for your use-case.
Example:

#[derive(SerializeRow)]
#[scylla(crate = scylla)]
struct MySerializeRow{
// some contents
}

Thanks for the quick response, it's working as expected.

@Lorak-mmk I also don't understand the exact difference between SerializeRow and SerializeCql. Both can be derived on a struct and inserting and retrieving it from the database holds the same result. For Catalytic, which one should I prefer using?

@Lorak-mmk I also don't understand the exact difference between SerializeRow and SerializeCql. Both can be derived on a struct and inserting and retrieving it from the database holds the same result. For Catalytic, which one should I prefer using?

I think my answer in your other thread mostly answers this.
What do you mean by "the same result"? If you derive SerializeCql (we should have named it SerializeUdt...), you will be able to use it as an element of query parameter list, but not the whole list, while if you derive SerializeRow you will be able to use it as whole parameter list, but not a single element of it. Those are not interchangeable.

@Lorak-mmk Yes, the answers in the other thread answered my questions I had. Renaming the derive macro to SerializeUdt would omit some concerns I had. I went with SerializeRow, thanks.