Allow serialization of "columns" that are not valid rust identifiers

[nrxus]

Fixes

When trying to serialize a row that isn't a valid rust identifier, the macro fails to expand due to the invalid rust identifier being used when creating variables for the derived implementation. This PR fixes that such that those variables are driven by the field identifier rather than the column name.

In particular, this occurs when trying to serialize a dynamic TTL that would be using in a query such as:

INSERT INTO my_table (/* snip cols */) VALUES((/* snip cols */) USING TTL ?

The struct desired for serialization is:

struct InsertRow {
    #[scylla(rename = "[ttl]"]
    ttl: i32,
    /* snip cols */
}

However, in the current version of the driver this fails because it tries to create a variable called visited_flag_[ttl] which is not a valid rust identifier. As far as I could tell there is no reason for this variable to be based on the column name rather than the field name so I switched it to be based off the field name since that already has to be a valid identifier.

I added a test to verify that the serialization works but I didn't add any integration tests to make sure that the TTL insert actually works. I have tested it locally however.

For context: I am using this dynamic TTL to allow moving of rows to different "buckets" (which drive partitions in my schema). I want the re-bucketing to not affect the existing TTL so I am reading the existing TTL in one query and then applying it to the new row in the new bucket in an insert.

I also fixed a doc typo that was missing an ending square bracket.

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.

[github-actions]

cargo semver-checks found no API-breaking changes in this PR! 🎉🥳
Checked commit: 8b579e6

[Lorak-mmk]

@piodul I don't see anything wrong with this change, but you wrote those macros so it would be good if you took a look - maybe I missed something.
@wprzytula Do we need the same change for deserialization?

[piodul]

Looks good, but I believe we have exactly the same issue in SerializeValue as well. @nrxus could you fix it in this PR, too? The fix should be very similar to what you did in the first commit.

[Lorak-mmk]

Looks good, but I believe we have exactly the same issue in SerializeValue as well. @nrxus could you fix it in this PR, too? The fix should be very similar to what you did in the first commit.

Is it possible to have UDT field names that are not correct Rust identifiers?

[piodul]

Looks good, but I believe we have exactly the same issue in SerializeValue as well. @nrxus could you fix it in this PR, too? The fix should be very similar to what you did in the first commit.

Is it possible to have UDT field names that are not correct Rust identifiers?

Apparently, yes:

cqlsh> create type ks.x ("a$a" int);
cqlsh> describe ks.x

CREATE TYPE ks.x (
    "a$a" int
);
cqlsh> 

[wprzytula]

@wprzytula Do we need the same change for deserialization?

This is how Deserialize{Row,Value} builds a visited flag variable's ident:

    fn visited_flag_variable(field: &Field) -> syn::Ident {
        quote::format_ident!("visited_{}", field.ident.as_ref().unwrap().unraw())
    }

So it should be free of the mentioned limitation.

[wprzytula]

💯 Thank you for this contribution, @nrxus!

[Lorak-mmk]

Thanks for the contribution! We plan to release 0.15.1 this or next week, it will contain your patch.