Foreign Key Marker

[liabri]

Hello,

I am wondering of the possibility to mark foreign_keys in models the same way primary_keys are marked. This would allow the entry of the foreign_key to exist directly inside the model. I imagine the syntax to be something like: #[sea_orm(foreign_key)], in the case of Fruit and Cake (as per the example provided in examples/basic) I would imagine it to be like this:

pub struct Fruit {
    #[sea_orm(primary_key)]
    id: u32,
    name: String,
    #[sea_orm(foreign_key)] //referring to the primary_key of the model "Cake" as marked in the data type in the line below
    cake: Cake, //note here, instead of cake_id it would contain the Cake directly
}

pub struct Cake {
    #[sea_orm(primary_key)]
    id: u32,
    name: String,
}

Queries utilising JOIN should make this quite feasible, but if the idea of containing the model directly within another model destroys the model (I cannot think of a synonym x)) of this project, maybe this foreign_key marker could reduce boiler plate for defining relations.

[billy1624]

Hey @lbcat06, welcome!! I see the potential use case of it in web API.

I'm thinking if it's only for selecting data from the database (readonly)? Or, it's mutable and can use for saving data back into the database?

[liabri]

I am not too well versed in SQL so I'm not quite sure whether writing operations using JOIN are feasible (I do think it is, so I think making it mutable would be great), but I am sure it would be feasible for readonly JOIN operations. Ideally it would be both, as this would allow to denormalise the data for more intuitive use within APIs and such.

[tyt2y3]

I think the type definition of cake: Cake is bad as it makes the size of the struct much larger.
It could better be cake: Option<Box<Cake>>, which means 'a nullable pointer to Cake'.
Then it leaves open a lot of API behaviour to define.

[liabri]

I think the type definition of cake: Cake is bad as it makes the size of the struct much larger. It could better be cake: Option<Box<Cake>>, which means 'a nullable pointer to Cake'. Then it leaves open a lot of API behaviour to define.

Sounds like a good idea, I am not sure how passing that over a web api would work though.

[PauMAVA]

Hey! I am pretty interested in this feature being added to sea-orm. I would even be willing to develop it myself.

First of all regarding @lbcat06 concern on how a Box<T> would show over web API I have tested it using a really simple rocket app you can find in this gist. There is no problem in sending a Box<T> via API as serde automatically implements Serialize for Box<T> whenever T implements Serialize.

Regarding the feature, I have some ideas on how to implement this but I am not sure 100% on where to start and the implications of an addition like this to sea-orm. I think there are two main parts for the development of this feature:

• Modifying the executor part to correctly obtain and build the associated struct.
• Creating the appropriate codegen and macros for code generation.

Apart from this, I have multiple questions:

• It would be better to use a JOIN clause and build the struct using an identifier for the associated table so that repeated fields (with the same name) on both tables can be identified correctly? Or maybe a subquery?
• Basically I would also need a little bit of help and advice from someone that knows sea-orm better as I am pretty new to this project.

Cheers! 😄

[billy1624]

Hey @PauMAVA, thanks for reaching out!! We love to see more and more contributors joining in!

@RomainMazB are you working on this? #415

[RomainMazB]

@RomainMazB are you working on this? #415

I am working on #415 yes (not the foreign_key). I have to admit that I may have to learn some few things about trait types and other stuff in the rust's typing-system to succeed but yes, I'm actively working on it.

[PauMAVA]

Hello @RomainMazB ! That's good as we will need the save methods in order to make the foreign_key feature writeable. We can continue discussing the API you propose in #415.

[tyt2y3]

As explained in https://www.sea-ql.org/blog/2022-05-14-faq-01/ this API style is not the best fit for Rust