#[derive(Item)] fails silently when #[dynomite(partition_key)] missing

[emturner]

related: #64, #65

🐛 Bug description

#[derive(Item)] on struct <name> requires a field to have the #[dynomite(partition_key)] applied to it (as per the docs). However, when this is missing, the derive fails silently, leading to the slightly cryptic error message:
the trait 'dynomite::Item' is not implemented for '<name>' when trying to derive Item for another struct of which <name> is a member

🤔 Expected Behavior

the following should produce an error (that #[derive(Item)] requires #[dynomite(partition_key)] on a field:

use dynomite::{Item, Attribute};

#[derive(Item, PartialEq, Debug, Clone)]
pub struct Author {
    //#[dynomite(partition_key)]
    name: String,
}
 
#[derive(Item, PartialEq, Debug, Clone)]
pub struct Book {
    #[dynomite(partition_key)]
    title: String,
    author: Author,
}

uncommenting the #[dynomite(partition_key)] then compiles

👟 Steps to reproduce

run cargo check on a crate containing the above

🌍 Your environment

dynomite version: 0.6.0

rustc version: 1.39.0-nightly

[softprops]

Thanks for reporting the issue. This may be a recent regression. This sounds like a bug

[softprops]

Thinking this case could be caught and reported somewhere around here

[softprops]

I'm in this area of the code for another issue so I think I'm going to grab this for the next release. To demonstrate how bad the current UX is here's an example of removing the partition_key attribute.

error[E0277]: the trait bound `std::option::Option<std::vec::Vec<Author>>: dynomite::Attribute` is not satisfied
  --> dynomite/examples/demo.rs:29:10
   |
29 | #[derive(Item, Debug, Clone)]
   |          ^^^^ the trait `dynomite::Attribute` is not implemented for `std::option::Option<std::vec::Vec<Author>>`

compiler errors show be informative and tell you how to fix an issue. This is neither!

[softprops]

fixed in #115