Sqlbolt has been good so far, just started myself

Indeed it does haha, thanks

I’m new to multithreaded programming. How would some other thread create it? Like what’s the real-world scenario?

I think I had that in a few attempts, I can’t remember why I removed it. Thanks for pointing this out.

I managed to get this working, but there has to be a better way. How else could I write this?

  pub async fn insert_or_return_user(
        db: &DbConn,
        partial_user: Auth0UserPart,
    ) -> Result {
        let user = users::ActiveModel {
            email: Set(partial_user.email.to_owned()),
            email_verified: Set(partial_user.email_verified.to_owned()),
            auth0_sub: Set(partial_user.sub.to_owned()),
            ..Default::default()
        };

        let result = user.clone().insert(db).await;

        match result {
            Ok(u) => {
                println!("{u:#?}");
                Ok(u.try_into_model().unwrap() as UsersModel)
            }
            Err(error) => {
                let user = Users::find()
                    .filter(users::Column::Auth0Sub.eq(&partial_user.sub))
                    .one(db)
                    .await?;

                Ok(user.unwrap() as UsersModel)
            }
        }
    }

It should be wrapped in an array, not an object. Then it’s valid. The problem was that I was trying to use an enum.

Yes, that’s what I meant, but no I can’t edit it :/

I got the response wrong, here’s what I’m using that isn’t working:

enum NationResponse {
    Nation(Nation),
    People(Vec),
}

Why the heck can’t I edit the original post after a comment is made?

Oh man, I didn’t know debug_handler existed. Sure enough I had a missing derived attribute… not sure how but Serde serialize and deserialize were missing, so when I was trying to return Ok(Json(army)) it was failing. Thanks so much!

Thanks for the reply! I don’t know what you mean by extensions, but the state is literally just the DB connection:

struct AppState { conn: DatabaseConnection, }

Nice, thanks… looking into these now.

🤔 I thought lazy_static was deprecated in favor of one_cell

Also, move out special types to types.rs, error types to errors.rs to keep the area with the actual algorithms more clear.

Ok this is totally something my code base needs. Very actionable feedback.

And yeah that’s one of the things I love about rust; it will tell me everywhere things are out of wack. It’s such a different experience from back when I had large JavaScript code bases. Make changes and pray lol.

This is really good to hear, I don’t think I’m as far off base as I thought; maybe I’ve been over thinking it a bit. And thanks for that refactoring resource. I’m very big into making my TS code clean and maintainable. I’m just thrown off a bit with the new paradigm.

This is a great answer, thanks. I’ll have to look more into conditional compilation. That’s new to me.

Nothing I guess. I just was thinking there would be more to it than that.

Thanks, yeah it felt like too many tests to keep in file. I can live with that directory approach. TY!

Error handling was kind of a pain to wrap my head around within the Rust Ecosystem, between the different crates, custom enums and learning about Box<dyn Error>. I do enjoy errors now that I understand how the community is using them a little better, and the idea of there being one control flow with errors being a possible ‘result’.

Author seems to have some good experience composing errors in Rust applications… good read!

This is cool. I’m a front-end focused dev by trade and have been 11 years now. I’ve been picking up Rust as a side hobbie for 6 months or so and have not even peaked at these front-end frameworks. I know Lemmy is all about Rust, but I still think it’s pretty cheeky they’re using Rust for the front-end.

About Leptos specifically… If there’s no shadow dom / rerenders and not trying to be react, I already like it better than it’s competitor.

I’d provide more code but it’s a mess and full of old commented-out code. Your examples are perfect! combining the DB fields into it’s own struct is something I hadn’t thought of… and I totally get why having a bunch of options sitting in the Army struct would be problematic. I’m really excited about rust for moving these sorts of errors to compile time.

The INTO example seems great too. I’m ok with the performance hit of cloning for now… lifetimes and pointers feel like a tier above where am at with my rust skills, and I’ll circle back to get a better handle on them later.

One question about the INTO example… I always hear it’s better to just implement FROM and get INTO for free. Does that not make sense for my use case? If I did it, would it look something like:

impl From<ArmyWithDbProps> for Army { fn from(self) -> ArmyWithDbProps { self.armyWithDbProps } }