search

jonra1993 / fastapi-alembic-sqlmodel-async

This is a project template which uses FastAPI, Pydantic 2.0, Alembic and async SQLModel as ORM. It shows a complete async CRUD using authentication and role base access control.
MIT License
964 stars 150 forks source link

Questions concerning Relationship definition #55

Closed vi-klaas closed 1 year ago

vi-klaas commented 1 year ago

Hi @jonra1993 , I have questions on the Relationship usage, class Hero:

Why not add a created_by_id to the HeroBase instead of Hero? Why is it Optional, or can it be required, since we always have a user that created a hero?

Where can I find information, which sa_relationship_kwargs I should use, and should there be another one to define what happens if records are deleted?

And also: why no backpopulates with the created_by relationship? Do we really need the primaryjoin argument?

vi-klaas commented 1 year ago

lazy: medium article

jonra1993 commented 1 year ago

Hello, @klav-zhaw related to your questions.

  1. I think it is relative to design requirements in this case create_by info, in general, is not really important information and is not required also if you think that this data can be empty on a seed. But there are other really important and required like secret_name for example. That is the logic and responding your question about why it is in Hero and not in HeroBase it is also related usually I add fields on HeroBase thinking of the most important fields that are 100% needed to create a new register in the database and also that when I create the IHeroCreate just inherit from HeroBase. Make it required will be a design requirement if your application considers that created_by_id is really important so you can move it to HeroBase and it will be required on the endpoint. Also you can see that the template create crud also accept a created_by_id here

  2. Despite that app uses sqlmodel remember that it is just a layer above sqlalchmey so you can use everything of that just that is imported by sqlmodel. I also check the sqlalchemy documentation. The advantage of sqlmodel instead of pure sqlalchemy is that you are not required to rewrite fields on schemas.

  3. You can use back populate. This sample also use some but I really do not like to use it because it brings from db data that is not always required which causes delays and a decrease in speed when requesting info on an endpoint but also as it is dual backpopulate should be done in the other relation which causes two no needed request of data. I prefer just to create custom SQL queries with join when it is required. In this special case, I do not think the created_by field is really important in order it consume backend resources to get that info in each request. But maybe it can be on some statistics apis in such case just a join should be done. But if you consider this kind of data is really important your app a backpopulate is a good option.

  4. Related to lazy options you can check this issue it can provide you with more information https://github.com/jonra1993/fastapi-alembic-sqlmodel-async/issues/20