Any good ways to handle object contains option<T> on updating?

[Dennis-Zhang-SH]

pub struct UpdateUserInfo {
    pub address: Option<String>,
    pub role_id: Option<i32>,
}

pub async fn update_user(
    Path(id): Path<i32>,
    c: JwtClaims,
    Json(payload): Json<UpdateUserInfo>,
) -> ... {
        ...
        let mut v: Vec<db::user::SetParam> = vec![];
        if let Some(x) = payload.address{
            v.push(db::user::address::set(x));
        }
        ... // for each filed
        client
                .user()
                .update(db::user::id::equals(id), v)
                .select(user_out::select())
                .exec()
                .await?
}

Is there a better solution than this? I am working on writing a proc_macro_attribute also.

[Brendonovich]

Personally I like this approach:

pub struct UpdateUserInfo {
	pub address: Option<String>,
	pub role_id: Option<i32>,
}

let payload: UpdateUserInfo = ...;

let values = [
	payload.address.map(db::user::address::set)	
].into_iter().flatten().collect();

client
	.user()
	.update(db::user::id::equals(id), v)
	.select(user_out::select())
	.exec()
	.await?

I've also thought about giving each module a partial! macro that can build a struct with certain fields, it'd just be tricky supporting arbitrary attributes and derives.

[Brendonovich]

Oh just find out that set fn of some fields requires Option, others requires T, that's a tricky one...

Yeah with the derive approach it wouldn't be uncommon to require Option<Option<T>> for some fields.

I managed to get this working and I think I prefer it. It can inherit existing serde and specta functionality, and doesn't require knowing the exact type for each field. It doesn't exactly allow for adding extra fields which would be annoying for something like rspc (but that could be done with some custom syntax), but it's more inline with what already exists and is imo easier to implement.

user::partial!(struct UserPartialType {
    name
    email
});

#[tokio::test]
async fn scalars() -> TestResult {
    let client = client().await;

    let user = client
        .user()
        .create("Brendan".to_string(), vec![])
        .exec()
        .await?;

    let updates = UserPartialType {
        // no update
        name: None,
        // update optional field with Option<Option<T>>
        email: Some(Some("brendonovich@outlook.com".to_string())),
    };

    let updated_user = client
        .user()
        .update(user::id::equals(user.id), updates.to_params())
        .exec()
        .await?;

    assert_eq!(
        updated_user.email,
        Some("brendonovich@outlook.com".to_string())
    );

    cleanup(client).await
}

[Dennis-Zhang-SH]

Okay, but why do you need a Option<Option<T>>, does that mean all my update struct needs to be written in a way like:

pub struct UpdateInfo {
    pub name: Option<Option<T>>
}

I wonder the macro implementation.

[Brendonovich]

Say User is this model:

model User {
    id             String     @id @default(cuid())
    name           String
    email          String?    @unique
}

The corresponding SetParam enum is something like this:

enum SetParam {
  Id(String),
  Name(String),
  Email(Option<String>),
}

And when we use partial! it makes each field you specify optional:

user::partial!(struct UserPartial {
  name
  email
});

// generates

struct UserPartial {
  name: Option<String>,
  email: Option<Option<String>>
}

So Option<Option<T>> wouldn't always be necessary, only for optional fields. You then get into the issue of handling them properly with serde (which PCR can do automatically), and it's just annoying to type. May as well tell PCR what fields you want and let it generate the struct itself.

[Dennis-Zhang-SH]

Oh, are you going to reform the Set function into set(Option), so that Option<Option> could be flatten and used in the set fn?

[Brendonovich]

No need, we can use the map ... flatten trick I shared earlier to implement to_params:

impl UserPartial {
  pub fn to_params(self) -> Vec<SetParam> {
    [
      self.name.map(user::name::set),
      self.email.map(user::email::set),
    ].into_iter().flatten().collect()
  }
}

Since each field of UserPartial is the original field but wrapped in Option, we can just map everything and the types all work out.

[Brendonovich]

model::partial! is now available on main if you want to try it out!

[Brendonovich]

Yeah it's not supposed to support relations yet since PCR doesn't support nested writes

[Dennis-Zhang-SH]

Yeah it's not supposed to support relations yet since PCR doesn't support nested writes

Okay, you can test on my repo now.

[Brendonovich]

it looks like you used the wrong rev, but there were issues on my end too. c7e2368cb624e1647853e14617afaf32c14365b7 should do the trick.

[Dennis-Zhang-SH]

it looks like you used the wrong rev, but there were issues on my end too. c7e2368cb624e1647853e14617afaf32c14365b7 should do the trick.

I changed it locally and it didn't work, so I changed it back, c7e2368cb624e1647853e14617afaf32c14365b7 works fine.

[Dennis-Zhang-SH]

it looks like you used the wrong rev, but there were issues on my end too. c7e2368cb624e1647853e14617afaf32c14365b7 should do the trick.

Hey I checked your repo in your homepage, I am really interested in spacedrive, is there any way I can contribute? I am a fullstack developer spent most time on devops and rust, I saw you guys are hiring Senior Front-end developer, well I am not that good at frontend but I think I can learn about it. Currently I can do part-time job, you can assign tasks to me, no salary is needed, but will need it if turn into full time job:).