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 question 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,
}
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.
Is it possible to add an ALIAS
clause after the FETCH
clause in order to map that value to a custom field? Or is there already a different workaround to achieve this behavior that I’m not aware yet?
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<CommemorationRef>>,
}
#[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?