I’m having some trouble on finding out the best way to deal with some relations in my Surrealdb project. As you can tell by this discussion title, I’m using Rust SDK.
I have the following structs on tables, therefore entities:

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq)]
pub struct LiturgicalDateEntity {
    pub id: Thing,
    pub time: LiturgicalTime,
    pub day: u8,
    pub month: u8,
    pub year: i32,
    pub commemorations_ids: Vec<Thing>,
    pub commemorations: Option<Vec<CommemorationEntity>>,
}

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq)]
pub struct CommemorationEntity {
    pub id: Thing,
    pub category: CommemorationCategory,
    pub color: LiturgicalColor,
    pub gospel_id: String,
}

A few questions have risen from my current work.

1. Is there any value on implementing a custom Serialize and Deserialize for enums, in order to store data more efficiently (specially when it comes to enums)? I mean, by simply deriveing Serialize and Deserialize traits for my enums, I get the following record (as seen on Surrealist), for CommemorationEntity entity:

{
    category: {
        Memorial: 10
    },
    color: 'Red',
    gospel_id: 'matt_7:10-12',
    id: commemorations:st_barnabas_apostle
}

But, by implementing custom Serialize and Deserialize traits, I was able to store the following:

{
    category: 'M_10',
    color: 4,
    gospel_id: 'matt_7:10-12',
    id: commemorations:st_barnabas_apostle
}

From the storing space point of view, it makes little sense to convert enums such as LiturgicalColor to a number, since as mentioned in documentation for data types, int should be a i64, which takes 8 bytes, while the String values stored from derived traits, usually takes less than 8 bytes. But, what about the following enum:

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum CommemorationCategory {
    Solemnity(u8),
    Feast(u8),
    Memorial(u8),
    OptionalMemorial(bool),
    Regular,
}

I’ve seen that storing it without custom Serialize/Deserialize, an Object(1) gets stored. In that case, I’d assume that simply storing serialized values of String up to 4 chars in length would be more memory efficient, am I wrong?

Besides, as mentioned in the documentation, storing byte arrays is also a possibility, so, assuming that I’d love to be the most efficient as possible, would I get value, in terms of memory usage, on storing enums as byte arrays instead of using the derived implementations, or am I missing anything fundamental on how data is stored in Surrealdb in this case?

2. When it comes to storing relations, I’m using two fields in the the example above, commemorations and commemorations_ids. The former one is supposed to get the relations, obtained via SELECT queries using the FETCH clause, while the latter simply stores the records.
While the data structure above works, it makes me take a non-intuitive approach on how to store data. For instance, in order to create a new LiturgicalDateEntity, I need to instantiate the following struct:

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq)]
pub struct CreateLiturgicalDateEntityDto {
    pub time: LiturgicalTime,
    pub day: u8,
    pub month: u8,
    pub year: i32,
    pub commemorations: Vec<Thing>,
}

which creates the record running the code briefly written below:

let new_liturgical_date: CreateLiturgicalDateEntityDto = CreateLiturgicalDateEntityDto {
        time: LiturgicalTime::Ordinary,
        day: 11,
        month: 6,
        year: 2024,
        commemorations: vec![(
            String::from("commemorations"),
            String::from("st_barnabas_apostle"),
        )
            .into()],
    };
let result: Result<Option<LiturgicalDateEntity>> = client // Surreal<Client>
.create(("liturgical_dates", "11-6-2024"))
.content(new_liturgical_date)
.await?;

And in order to retrieve that data, I need to run this query: SELECT *, commemorations as commemorations_ids FROM liturgical_dates:⟨11-6-2024⟩ FETCH commemorations.

So far, so good, it works. But I find it non-intuitive to store the ids at commemorations field, as ideally, it should be stored at commemorations_ids field. Besides, if I don’t add the FETCH clause at the end of the query, I get the following error:
"Failed to convert `[{ commemorations: [commemorations:st_barnabas_apostle], commemorations_ids: [commemorations:st_barnabas_apostle], day: 11, id: liturgical_dates:⟨11-6-2024⟩, month: 6, time: 0, year: 2024 }]` to `T`: missing field `tb`", regardless of setting this field as optional (By having it wrapped in an Option).

I can tell that the struct deserialization is expecting to receive a Vec<CommemorationEntity>, not a Vec<Thing>, so that the error. So, a few questions arise.

First, is it possible to add an ALIAS clause after the FETCH clause in order to map that value to a custom field? I’ve searched the issues and didn’t find any suggestion in that regard. I believe that Surrealdb would benefit greatly from this implementation, unless there already is a different workaround to achieve this behavior that I’m not aware yet.

Second, what approach should I take in order to properly deserialize the commemorations field, by being have to receive both a Vec of records (CommemorationEntity) or references (Thing), without calling the FETCH clause? I’ve tried using two solutions listed below, to no avail:

pub struct LiturgicalDateEntity {
    ...
    pub commemorations: Option<Vec<CommemorationEntity>>,
}

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq)]
pub enum CommemorationsRef {
    Ids(Vec<Thing>),
    Records(Vec<CommemorationEntity>)
}```
This approach yields: ```Failed to convert `[{ commemorations: [commemorations:st_barnabas_apostle], day: 11, id: liturgical_dates:⟨11-6-2024⟩, month: 6, time: 0, year: 2024 }]` to `T`: missing field `tb` ```
and 

pub struct LiturgicalDateEntity {
…
pub commemorations: Option<Vec>,
}
#[derive(Debug, Serialize, Deserialize, Clone, PartialEq)]
pub enum CommemorationRef {
Id(Thing),
Record(CommemorationEntity),
}

In turn, this yields:
```Failed to convert `[{ commemorations: [commemorations:st_barnabas_apostle], day: 11, id: liturgical_dates:⟨11-6-2024⟩, month: 6, time: 0, year: 2024 }]` to `T`: invalid value: map, expected map with a single key```
I'm assuming that this level of abstraction is possible and certainly I'm not taking the correct approach for cases like that. If so, how can I achieve the expected behavior explained above?

Thanks in advance.