Compiler warnings about member name casing when deriving Item and renaming partition/sort key
naamancurtis opened this issue ยท 3 comments
๐ Bug description
When deriving an Item
on a struct and also using the rename attribute to rename a field marked as a partition_key or sort_key, a compiler warning is issued on cargo check | build | run
. This warns that the field should have a snake case name. It doesn't seem to have any material impact other than the warning on compile, any code I've written so far using the structs appears to work as intended, but I'm not sure if this might have some effects further down the line? If it is just superficial it might be something that's worth calling out in docs?
๐ค Expected Behavior
No warning should be issued on cargo
+ check
| build
| run
๐ Steps to reproduce
# Cargo.toml
[package]
name = "test_dynomite"
version = "0.1.0"
edition = "2018"
[dependencies]
dynomite = "0.8.2"
// src/main.rs
use dynomite::Item;
#[derive(Debug, Item)]
pub struct MyStruct {
#[dynomite(partition_key)]
#[dynomite(rename = "myId")]
my_id: String,
#[dynomite(rename = "mySubId")]
#[dynomite(sort_key)]
my_sub_id: u32,
}
fn main() {
let my_struct = MyStruct {
my_id: "Hello".to_string(),
my_sub_id: 10,
};
println!("{:?}", my_struct);
}
Running cargo run
> cargo run
warning: structure field `myId` should have a snake case name
--> src/main.rs:7:5
|
7 | my_id: String,
| ^^^^^ help: convert the identifier to snake case: `my_id`
|
= note: `#[warn(non_snake_case)]` on by default
warning: structure field `mySubId` should have a snake case name
--> src/main.rs:10:5
|
10 | my_sub_id: u32,
| ^^^^^^^^^ help: convert the identifier to snake case: `my_sub_id`
Finished dev [unoptimized + debuginfo] target(s) in 0.54s
Running `target/debug/test_dynomite`
MyStruct { my_id: "Hello", my_sub_id: 10 }
๐ Your environment
dynomite version: 0.8.2
rustc version: 1.43.1
Os: MacOS
That's definitely not the intent. Thanks for reporting the issue
I think I found this source in the last pull
dynomite/dynomite-derive/src/lib.rs
Line 479 in 62be32a
I'm not exactly sure why we rename fields for the key struct but I'll get to the bottom of it. This is on my list for the next release