edgedb-tokio-ext
A library of common helper traits, macros & functions when working with edgedb-rust
Serde Extension
This library implements SerdeClientExt and SerdeTrxExt on edgedb_tokio::Client and edgedb_tokio::Transaction respectively. There are two traits as on Transaction a mutable ref is required to run client functions and also the futures are not Send. To use this trait and seamlessly deserialize edgedb query return values into your serde structs import the trait.
use SerdeClientExt;
use Deserialize;
use Uuid;
async
Tip: this works really well when you have a polymorphic query that can return different subtypes of an abstract type, just use an enum and annotate with #[serde(untagged)].
Shaped queries
To avoid the hassle of having to always edit your queries when you edit the struct you want them to deserialize into I created two macros: Shape and shaped_query.
The macro takes care of creating a shape function that returns a &'static str with the body of the field selection. The macro expansion works recursively as well, and the projection for Organization will be applied to the organization field in User.
To interpolate the field selection into an EdgeDB query use the shaped_query! macro:
let edgedb_client = create_client.await.unwrap;
let query = shaped_query!;
let user = edgedb_client
.
.await
.unwrap;
assert_eq!;
The macro attributes are quite simple:
nesteduse this attribute if your field needs to expand the subtype.expthis attribute allows you to pass in the right hand side of the assignment, its exclusive withalias. You could build a named tuple inside of the expression that then is picked up by theQueryablestruct or just follow a link and a property, destructure a named tuple field and much more... It's up to you how to use thisaliasUse this attribute if your struct field and the edgedb type field have different names. It is a shorthand forexp = ".fieldname"
Tx Variant
There is an issue with code that should accept both a &edgedb_tokio::Client OR &edgedb_tokio::Transaction since there is no trait that unifies them. Transaction creates futures that are not Send and also requires a mutable reference to be used, this would make functions using such a trait quite limited for the cases they are used with a Client and not a Transaction. I still think there would be value in such a trait, however to fit my current needs I created the tx_variant macro that creates a function with the exact same name followed by _tx that accepts &mut Transaction rather than &Client.
This macro is still a thought experiment as for example the inner function body wouldn't replace calls to other DB functions with their tx variant (yet!), however it can still be useful to cut down on duplicated code.
async
Generates:
async