What did you implement:

This should be useful when we have fat enums support in dynomite (https://github.com/softprops/dynomite/issues/131), for enum variants to be able to be used as partition/sort keys.

This works like #[serde(flatten)], the fields of the nested struct are flattened to the attributes of the surrounding struct where the flattened field is declared. The reverse mapping is done when parsing the struct from raw Attributes.

How did you verify your change:

Added a unit test, compile_fail test, and documentation (doc test)

What (if anything) would need to be called out in the CHANGELOG for the next release:

• Introduce #[dynomite(flatten)] field attribute UPD
• BREAKING CHANGE FromAttributes now requires the impl of fn from_mut_attrs(attrs: &mut Attributes) instead of from_attrs(attrs: Attributes), the latter now has the default impl based on from_mut_attrs impl

New to rust and dynomite here, so sorry if it's a dumb question, but I couldn't find any example or documentation on how to deal with optional attributes. I am used to other libraries/languages where we can specified certain attributes as "nullable" meaning that if they are not set the value is set to null/None.

In other words if I have something like this:

[derive(Item, Debug, Clone, GraphQLObject)]
struct Event {
    #[dynomite(partition_key)]
    id: String,
    status: String,
}

Some events won't have the attribute status set, for example. When calling Event::from_attrs(result) I am getting a MissingField error, instead of getting a None value.

I tried this too but didn't seem to make a difference:

[derive(Item, Debug, Clone, GraphQLObject)]
struct Event {
    #[dynomite(partition_key)]
    id: String,
    status: Option<String>,
}

Is there a way to deal with this?

Thanks for the help.

What did you implement:

Renamed attributes hash to partition_key and range to sort_key.

See reasoning in #69.

Closes: https://github.com/softprops/dynomite/issues/69

How did you verify your change:

$ cargo test # all non-ignored tests pass

$ rg -t rust -w hash | wc -l
       0

$ rg -t rust -w range | wc -l
       0

$ rg -t rust -w partition_key | wc -l
      10

$ rg -t rust -w sort_key | wc -l     
       4

What (if anything) would need to be called out in the CHANGELOG for the next release:

This is a breaking change so we should call out the rename and probably bump to 0.6.

What did you implement:

Added a cargo feature to the crate which allows end users to easily serialize std::time::SystemTimes into human readable rfc3339 timestamps, by implementing Attribute for SystemTime and using humantime's implementation of rfc3339 timestamps internally.

How did you verify your change:

Added 2 tests to lib.rs

What (if anything) would need to be called out in the CHANGELOG for the next release:

"Added support for rfc3339 timestamps through the humantime crate and feature"

What did you implement:

Implemented field renaming on Item-derived types via an attribute similar to serde's rename.

Example

#[derive(Item, PartialEq, Debug, Clone)]
struct Recipe {
    #[hash]
    #[dynomite(rename = "recipe_id")]
    id: String,
    servings: u64,
}

let value = Recipe {
    id: "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee".into(),
    servings: 2,
};

let attrs: Attributes = value.into();

println!("{:#?}", attrs); // see next code block

{
    "recipe_id": AttributeValue {
        b: None,
        bool: None,
        bs: None,
        l: None,
        m: None,
        n: None,
        ns: None,
        null: None,
        s: Some(
            "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
        ),
        ss: None,
    },
    "servings": AttributeValue {
        b: None,
        bool: None,
        bs: None,
        l: None,
        m: None,
        n: Some(
            "2",
        ),
        ns: None,
        null: None,
        s: None,
        ss: None,
    },
}

Closes: https://github.com/softprops/dynomite/issues/53

How did you verify your change:

$ cargo t field_rename
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running target/debug/deps/dynomite-ae35a6724a5f60c6

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 36 filtered out

     Running target/debug/deps/derived-b5a5da7206a8af0c

running 1 test
test tests::field_rename ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out

     Running target/debug/deps/dynomite_derive-050c7f0267e4327d

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

struct Recipe {
    #[hash]
    #[dynomite(rename = "recipe_id")]
    id: String,
    servings: u64,
}
impl ::dynomite::FromAttributes for Recipe {
    fn from_attrs(mut attrs: ::dynomite::Attributes) -> Result<Self, ::dynomite::AttributeError> {
        Ok(Self {
            id: ::dynomite::Attribute::from_attr(attrs.remove("recipe_id").ok_or(
                ::dynomite::AttributeError::MissingField {
                    name: "recipe_id".to_string(),
                },
            )?)?,
            servings: ::dynomite::Attribute::from_attr(attrs.remove("servings").ok_or(
                ::dynomite::AttributeError::MissingField {
                    name: "servings".to_string(),
                },
            )?)?,
        })
    }
}
impl ::std::convert::From<Recipe> for ::dynomite::Attributes {
    fn from(item: Recipe) -> Self {
        let mut values = Self::new();
        values.insert(
            "recipe_id".to_string(),
            ::dynomite::Attribute::into_attr(item.id),
        );
        values.insert(
            "servings".to_string(),
            ::dynomite::Attribute::into_attr(item.servings),
        );
        values
    }
}
impl ::dynomite::Item for Recipe {
    fn key(&self) -> ::std::collections::HashMap<String, ::dynomite::dynamodb::AttributeValue> {
        let mut keys = ::std::collections::HashMap::new();
        keys.insert(
            "recipe_id".to_string(),
            ::dynomite::Attribute::into_attr(self.id.clone()),
        );
        keys
    }
}
struct RecipeKey {
    recipe_id: String,
}
impl ::dynomite::FromAttributes for RecipeKey {
    fn from_attrs(mut attrs: ::dynomite::Attributes) -> Result<Self, ::dynomite::AttributeError> {
        Ok(Self {
            recipe_id: ::dynomite::Attribute::from_attr(attrs.remove("recipe_id").ok_or(
                ::dynomite::AttributeError::MissingField {
                    name: "recipe_id".to_string(),
                },
            )?)?,
        })
    }
}
impl ::std::convert::From<RecipeKey> for ::dynomite::Attributes {
    fn from(item: RecipeKey) -> Self {
        let mut values = Self::new();
        values.insert(
            "recipe_id".to_string(),
            ::dynomite::Attribute::into_attr(item.recipe_id),
        );
        values
    }
}

What (if anything) would need to be called out in the CHANGELOG for the next release:

Mention the new functionality!

Potential Follow-Up Work

#[dynomite(rename_all = "...")] similar to serde's rename_all.

Other Notes

~~This depends on #66 (and as such includes the commit from it).~~ #66 has been merged and this was rebased on top of it.

~~Blocked by (these PRS have to reviewed and merged first before this one):~~

• [x] ~~#134~~
• [x] ~~#132~~

Internally tagged enums

The docs are pretty self-explanatory. This PR adds support for simple fat enums that have either one-element-tuple variants of the nested value of type T such that T: Attributes, or unit variants.

use dynomite::Attributes;

#[derive(Attributes)]
#[dynomite(tag = "kind")] // required to specify for fat enums
enum Shape {
    Rectangle(Rectangle),
    // Use `rename` to change the **value** of the tag for a particular variant
    // by default the tag for a particular variant is the name of the variant verbatim
    #[dynomite(rename = "my_circle")]
    Circle(Circle),
    Unknown,
}

#[derive(Attributes)]
struct Circle {
    radius: u32,
}

#[derive(Attributes)]
struct Rectangle {
    width: u32,
    height: u32,
}

These Rust definition correspond to the following representation in DynamoDB for each enum variant:

• Rectangle:

  {
      "kind": "Rectangle",
      "width": 42,
      "height": 64
  }
  

• Circle:

  {
      "kind": "my_circle",
      "radius": 54
  }
  

• Unknown:

  {
      "kind": "Unknown"
  }
  

Closes: #131

How did you verify your change:

Added a unit test, trybuild tests and doc tests

What (if anything) would need to be called out in the CHANGELOG for the next release:

• Add initial support for fat enums (only one-element tuple variants of T: Attributes values and unit variants)

Tested:

• There are no breaking changes
• The changes are tested in integration tests for both successful and error (trybuild) cases

What did you implement:

This basically reflects serde::skip_serializing_if attribute. This will be very useful for us to get rid of manual workarounds where we need to store empty binary sets in a db record.

Also had to fix a clippy lint of implementing Into trait instead of From to let CI pass

How did you verify your change:

Ran tests. I've also moved integration tests into a single test binary as per this article

What (if anything) would need to be called out in the CHANGELOG for the next release:

The new feature is specified in changelog in this diff

What did you implement:

Updated rusoto* dependencies to 0.45 version I would appreciate if you could release this as a patch version to cartes.io, @softprops

How did you verify your change:

cargo test # worked fine for me

What (if anything) would need to be called out in the CHANGELOG for the next release:

Bump rusoto dependencies to version 0.45

I'm not sure if this is a bug, my mistake or this has not been implemented yet ...

🐛 Bug description

Nested structure

#[derive(Item, Serialize, Deserialize, Debug)]
struct t_list {
    #[dynomite(partition_key)]
    lid: Uuid,
    items: Option<Vec<t_list_item>>,
}

fails over items: Option<Vec<t_list_item>> with this error message

the trait bound `std::option::Option<std::vec::Vec<t_list_item>>: dynomite::Attribute` is not satisfied
the following implementations were found:
  <std::option::Option<T> as dynomite::Attribute>
required by `dynomite::Attribute::from_attr`rustc(E0277)
main.rs(134, 10): Error originated from macro here

🤔 Expected Behavior

I was hoping to get the structure similar to this

{
  "lid": "ff0540dd-3e1c-4977-8d54-5e044688dba1",
  "items": [
    {
      "liid": "30000000-012e-4dd7-9697-dcc06d148a64",
      "title": "... some text ..."
    },
    {
      "liid": "30000001-012e-4dd7-9697-dcc06d148a64",
      "title": "... some text ..."
    }]
}

👟 Steps to reproduce

Something as simple as

#[derive(Item, Serialize, Deserialize, Debug)]
struct t_list {
    #[dynomite(partition_key)]
    lid: Uuid,
    items: Option<t_list_item>,
}

where t_list_item is another struct should produce the same error.

🌍 Your environment

dynomite = {version = "0.8.2", default-features = false, features = ["rustls"]}

💡 Feature description

In some cases you don't always want all fields returned in queries when a simple projection will do. Make it easy to derive subset of item attributes

💻 Basic example

#[derive(Attributes)]
struct Attrs {
  field: String
}

vs

#[derive(Item)]
struct Foo {
  #[dynomite(partition_key)]
  id: String,
  field: String
}

What did you implement:

Closes: #83

How did you verify your change:

1. cargo build and cargo test -- option_.
2. Integration in separate project is working correctly.

What (if anything) would need to be called out in the CHANGELOG for the next release:

This PR fixes an issue with using None when sending PutItem request to the AWS API.

uuid has made a major 1.0.0 release and subsequent releases up to 1.1.2. Depending on dynomite while trying to upgrade uuid results in errors due to multiple crate versions.

What did you implement:

• Upgrade lambda_http to version 0.5.2
• Upgrade uuid to version 1.1.2
• Update failing trybuild test cases

How did you verify your change:

By running:

cargo build --all-targets
cargo test

What (if anything) would need to be called out in the CHANGELOG for the next release:

The new uuid version should probably be called out.

👋 Super excited that this project exists!

This PR fixes a small typo in an error message returned by make_dynomite_item. There shouldn't be an apostrophe here because, in this phrase, the item isn't being used as as a possessive.

This fixes an issue, whereby dynomite would not treat raw identifiers (r#…) properly as it would include the syntactical r# prefix in the serialized attribute values.

For example, the value of the following enum:

#[derive(Attribute, Clone, Copy, Debug, PartialEq)]
pub enum EnumWithRawFieldNameIdentifier {
    r#VariantName,
}

would be serialized as "r#VariantName".

With this fix it will be serialized as "VariantName", as, I think, expected.

It would be great to see support for using dynomite with Single Table Design.

https://github.com/jeremydaly/dynamodb-toolbox is a great option for TypeScript developers that could serve as inspiration.

Updates the requirements on env_logger to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.