cypher-dto-macros

Macros for working with the cypher-dto crate.

There are three types of macros contained:

1. Derive macros, which do most of the work.

   #[derive(Node)]
   struct Person {
     id: String,
     name: String,
     #[name = "zip_code"]
     zip: String,
   }
   
   #[derive(Relation)]
   struct Knows;
   

   These will implement cypher_dto::{FieldSet, NodeEntity, RelationEntity} for the structs.

   There are two helper attributes that come into scope when using the derive macros, #[id], and #[name].

   #[id] marks a field as being part of the entity's uniquely identifying set of fields. Multi-valued identifiers are supported this way. If none are specified and a field named id exists, that will be inferred to be the only id field. The set of id fields is given its own struct, e.g. PersonId, that can be obtained via person.identifier() or person.into().

   #[name] allows the property name in the database to be different than on the struct. #[name = "..."] and #[name("...")] are supported, and can be applied to the struct as well.

   A builder is also generated for each struct, e.g. PersonBuilder. It can be obtained via person.into_builder().

2. The #[timestamps] macro, which will add one or two timestamp fields to the struct. By default it adds two fields, created_at and updated_at, with the type Option<DateTime<Utc>>. Optional timestamp fields let the Person::new() implementation skip having them as arguments, which is how you would create a DTO in application code before it is created in the database.

   You can control which fields it adds by specifying certain values as a string (#[timestamps = "..."] and #[timestamps("...")] are supported). The values must be ONE of full (the default), short (created, updated), created_at, updated_at, created, or updated.