Best practice for handling READONLY field in Rust?

[kherge]

Assume I have a table that contains a READONLY field with a DEFAULT value set on record creation. In Rust, should I be using two different structs? One that has readonly fields and one that does not?

#[derive(Debug, Deserialize, Serialize)]
struct ForWriting {
    name: String,
}

#[derive(Debug, Deserialize)]
struct ForReading {
    name: String,
    order: i64,
}

Or is there another way to use a single struct for both? I tried using Option<i64> for order, but it seems that this prevents the DEFAULT value from being set.

[ActuallyHappening]

Yeah using two structs is the pattern I use, e.g.:

#[derive(Deserialize)]
pub struct User {
email: email_address::EmailAddress,
#[serde(rename = "password")]
hashed_password: Box<str>,
other_info: OtherInfo,
}

mod sign_up{
pub async fn sign_up_user(db: ..., user: SignUpUser) { ...}
#[derive(Serialize)]
pub struct SignUpUser {
  email: String,
  #[serde(rename = "password")]
  plaintext_password: String,
}
}

Although, relying on the DEFAULT clause in the database is usually not necessary, unless your abstracting over something that the database knows better than you as the client (i.e. using a DB connection) know. Your probably better to change your ForWriting to something like this:

pub mod writing{
#[derive(Debug, Serialize)]
pub struct ForWriting {
    name: String,
    order: i64,
}

const ORDER_DEFAULT: i64 = 69;
impl ForWriting{
 pub fn new(name: String) { ForWriting { name, order: ORDER_DEFAULT } }
 pub fn with_order(mut self, order: i64) -> Self { self.order = order; self }
}
}

That way when your consuming your own code, due to rust privacy restrictions (module boundaries), your guarenteed to provide the default but also have the option of changing it.
If you really want the DEFAULT clause, your going to probably need serde attributes to avoid passing Option::None as a value, which is still a surrealdb::Value and won't trigger the DEFAULT, maybe like this (don't know if this is accurate, never done it before):

#[derive(Debug, Serialize)]
pub struct ForWriting {
    name: String,
    #[serde(skip_serializing_if = "Option::is_none")]
    order: Option<i64>,
}

[kherge]

Interesting. I think I chose a bad example. Another issue related to this one is that I have a few fields that will only ever be set and updated database-side (e.g. created_at, updated_at, version). I was hoping to have a consolidated struct, but it seems like that is not something that might be supported at the moment.

[ActuallyHappening]

Yes, you can’t have your cake of memory safety and type safety and in one type be able to express two distinct serde/data models
This isn’t a surrealdb specific symptom, it is because Rust has a strong type system, and the only way to have a type guaranteed to have a created_at field and a type guaranteed not to is if they are different types
I actually prefer this, because it means your types better reflect the behaviour of your program and therefore you benefit from privacy rules, eg reading is pub but creating is private. This is a good example why it’s possible to only derive Serialize or Deserialize on a type, if you were forced to derive both at the same time a pattern like this would be more ambiguous at the type level

[kherge]

What brought up this quesiton was a weird interaction I had with SurrealDB using a struct similar to the following:

struct Combo {
  value: String,
  version: Option<i64>,
}

When I used the Rust SDK to create a record, the schema did not automatically populate the version field as it was configured to do. If I had to take a guess as to what happened, it feels like the following query was generated:

CREATE combo
   SET value = "example",
       version = NONE

It seemed that by specifying version in the struct and using None as the value I used to create the record, it disabled the auto populating function I had defined with the schema. Not sure if others had a similar experience, but I think it's the only reason I'm using two different structs.

[ActuallyHappening]

That is expected behaviour yes, use the VALUE clause instead of the DEFAULT clause if you want to enforce this, which I use very often

[kherge]

The query I provided is what I assumed to be generated by using db.create("comb").content(myStructInstance). Is it possible to use the VALUE clause with .create(), or would it be required to use .query() instead?

[ActuallyHappening]

You misunderstand, read the docs on the VALUE clause, it’s used in the DEFINE FIELD, e.g. DEFINE FIELD created_at VALUE time::now()

[kherge]

Ah, okay. Thanks!