**Carabao Dev Log**

I am heavily reworking and refactoring my database test creation with a builder pattern that feels pragmatic enough. Might have to make the skeleton into a macro again.

Anyway, I just found marking functions and structs `#[deprecated]` while refactoring to easily mark things I needed to change since `cargo clippy` issues a compilation warning. Not a novel approach I guess but just surprised I was able to use it.

Docs: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute

#carabao #rust #dev_log

**Carabao Dev Log**

Good news, I learned that marking `actix::Actor` as `actix::SystemService` makes it much more convenient for my setup and with the tests. It is just strange it is not in the main documentation.

Bad news, I was wrong about the global database connection and had to create a flag/guard for a per-thread test pool (of 1) so that the tests are consistent. The things I do for a test harness.

`actix::registry::SysemRegistry `: https://docs.rs/actix/latest/actix/registry/struct.SystemRegistry.html

#carabao #rust #dev_log

**Carabao Dev Log**

Just found out that `cargo fmt` can be used to format `Cargo.toml` files but the PR for it is not yet merged. Not sure I agree with the actual formatting, but I do want more a standard method and tool.

Github Comment: https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1519977712

#carabao #rust #dev_log

**Carabao Dev Log**

So creating an event bus with `actix` did involve some `macro_rules`. The type safety though of handlers is fascinating where each message must have a handler instead of letting it silently ignored.

On the testing side, I am surprised that testing database connections across multiple actors with their own pools still produce a consistent test result somehow as if they use a global test connection. 🤷

#carabao #rust #dev_log

**Carabao Dev Log**

I wish there was an quick event bus solution for `actix` where I am writing so many `impl Handler` to broadcast messages. If anybody wants to make that where you can just maybe register an `Actor` then just write the `Handler`s would be great. Yet I do think it might not be possible without some `macro` magic which would also be a dealbreaker.

Although this makes me reflect the things I neglected while working with /Elixir/ and its global registry.

#carabao #rust #dev_log

**Carabao Dev Log**

Writing tests for the OAuth entities now since I feel it is stable now. My current problem is now running a `diesel` transaction within a transaction since test connections use a test transaction via `conn.begin_test_transaction()`. Thankfully this is easy to resolve:

```
conn.begin_test_transaction();

/// DOES NOT WORK
/// conn.build_transaction().run(...);

/// WORKS
conn.transaction(...);
```

#carabao #rust #dev_log

**Carabao Dev Log**

Still fixing up my PR for adding a missing OAuth `client_credentials` but for now I came across this footgun with filtering `NULL` database fields with `diesel`. Instead of `field.eq(None)`, it was actually `field.is_null()` which kinda feels a little bad on the Rust side, but makes sense in SQL. (The fragment `table.field = NULL` is not the same as `table.field IS NULL`.)

Issue: https://github.com/diesel-rs/diesel/issues/1306

#carabao #rust #dev_log

**Carabao Dev Log**

I am so blind for not noticing there were async bindings for the critical traits in `oxide_auth` named `oxide_auth_async`. Would have saved me time from finding ways to run async functions inside non-async functions. Still have to integrate it a bit later though.

Github Issue: https://github.com/HeroicKatora/oxide-auth/issues/76#issuecomment-864237929
`oxide_auth_actix`: https://docs.rs/oxide-auth-actix/latest/oxide_auth_actix/

#carabao #rust #dev_log

**Carabao Dev Log**

Revelation, I was trying to make my error wrapping better. In particular, I was trying to convert a missing database entry error into an application specific error and doing `convert(action.await?)` feels lacking.

So I tried doing a simple `Extension Traits` for `anyhow` errors and it just feels good doing `action.await.not_found("app_id")?`.

Extension Trait: http://xion.io/post/code/rust-extension-traits.html
Anyhow Error: https://docs.rs/anyhow/latest/anyhow/struct.Error.html

#carabao #rust #dev_log

**Carabao Dev Log**

Almost close to finishing my initial crating refactoring. I came across this strange macro issue:

`type `fn(String) -> Wrapper {Wrapper}` is private
private type`

The issue is that I forgot to add `pub` to the inner wrapper type but the error was hard to understand behind a macro error.

The debugging tactic I used is to copy the output of `cargo expand` and get a better compiler error which took me longer to realize.

https://github.com/dtolnay/cargo-expand

#carabao #rust #dev_log

**Carabao Dev Log**

So I refactored my models to use the new typed de/serialization strategy and it feels good keeping the `diesel` dependency in one subcrate.

Sadly for ad-hoc query types like returning a few fields, I have to use the new wrapper types then convert them to its intended type which is a minor inconvenience.

The last gotcha is manually implementing `Nullable` since it is not automatically derived for custom types which is hard to detect.

Still a win

#carabao #rust #dev_log

**Carabao Dev Log**

OMG, `diesel` has `deserialize_as` and `serialize_as` which helps me in writing less macros and implementing less types. I need to rethink my approach here.

Insertable: https://docs.diesel.rs/master/diesel/prelude/derive.Insertable.html#optional-field-attributes
Queryable: https://docs.diesel.rs/master/diesel/deserialize/derive.Queryable.html#optional-field-attributes

#carabao #rust #dev_log

**Carabao Dev Log**

So I am in the process of splitting my project into multiple crates and it is somewhat relaxing and cathartic. Sadly, I am running into safe type conversions that are hard to refactor. I may have to bite the bullet to allow `unsafe` just for type conversions.

#carabao #rust #dev_log

**Carabao Dev Log**

At last, the OAuth2 intergration of `oxide-oauth` is working with `code` response type. I have been trying to figure out how it works and took so long. 😭 Just so happy it works but I have to add some protections like CSRF and so on.

#carabao #rust #dev_log

**Carabao Dev Log**

So I finally figured out why rendering an HTML body with `Yew SSR` then passing it to an `Askama template` never renders properly. It was because the `Askama` by default HTML escapes by default and I just had to disable that. 😅

```rust
#[derive(Template)]
#[template(path = "page.html", escape = "none")]
pub struct PageTemplate<'a> { }
```

#carabao #rust #dev_log

**Carabao Dev Log**

Cleaning up some test code and I realized that pool connections were not started in a transaction. If I did try to start a transaction, I get a transaction in a transaction error.

With `r2d2`, a pool can be configured to do this on connection checkout which is neat.

Snippet: https://pastebin.com/jLtuPKYP
r2d2: https://docs.rs/r2d2/latest/r2d2/trait.CustomizeConnection.html

#carabao #rust #dev_log

**Carabao Dev Log**

So stabilized my parse-validation macro and it looks like this:

```rust
#[derive(StructType)]
#[stype(tag = "accounts", constraint)]
pub struct RegisterAccount {
#[vtype(with = "AccountUsername", required, constraint)]
pub username: String,
#[vtype(with = "AccountPassword", required)]
pub password: SecretString,
}
```

Kinda took my time exploring macros but should get back to the main track.

#carabao #rust #dev_log

**Carabao Dev Log**

Getting better at making macros. Started using `proc_macro_error` to have better error message and reporting.

proc_macro_error: https://docs.rs/proc-macro-error/latest/proc_macro_error/

Still trying to get my test seeding macro to work nicely with `async_trait`. Some complication with the `Send` marker but worst case will revert to `async { seed() }.await` block.

async_trait: https://docs.rs/async-t

#carabao #rust #dev_log

**Carabao Dev Log**

So the reason I started learning macros is to make creating wrapper types easier. I have read **Zero to Production in Rust** and the validation section (6.3) or type-driven development struck a nerve with me.

> Parse, don't validate

I refactored my code to reflect this mind set but it is tough without a crate to support this. So I made one and possibly considering making it an open source crate if I can.

Article: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

#carabao #rust #dev_log

**Carabao Dev Log**

(Going to start writing some of my quick thoughts and notes here. Probably going to explain this sometime soon but just need an outlet right now.)

So far I learned to create some basic derive macros to create a custom parse-validator library. Right now, I hate myself for not checking out how to create derivable trait macros so that my trait and macro have the same name. Macro growing pains I guess.

Doc: https://doc.rust-lang.org/book/ch19-06-macros.html#how-to-write-a-custom-derive-macro

#carabao #rust #dev_log