[Discussion] CRUD system vs Model

[sheoak]

I am currently working on a backend based on this repository. I was wondering why the design choice of the "CRUD" classes as independant entities.

I was thinking about creating a base model for User model (and others, later) and put all the CRUD logic in it, without the need to pass the db every time. It would also remove the need for all the crud-related files.

For example:

from app.model.user import User
new_user = User.create(obj_in)
u = User.get_by_email("[email protected]")

compare to :

from app import crud
new_user = crud.user.create(db, obj_in=user_in)
u = crud.user.get_by_email(db, email=email)

Any thought on that?

[scil]

I would like the same style as you.

based on absent1706/sqlalchemy-mixins, I created scil/ sqlalchemy-mixins-for-starlette which support starlette and fastcgi by adding a new argument db to each API.

[sheoak]

I would like the same style as you.

based on absent1706/sqlalchemy-mixins, I created scil/ sqlalchemy-mixins-for-starlette which support starlette and fastcgi by adding a new argument db to each API.

Thank you! I will have a look if it works for me I will base my work on it and we can share efforts :)

[sheoak]

@scil could you give an example on how you use: create_from_schema init_from_schema

I'm not sure I undertand. I've been working on something using sqlalchemy-mixins without any modification for fastapi for now and I should release is soon. I will propably first make a base repository and then migrate to a pip package when it's mature.

[scil]

@sheoak I added a full example for create_from_schema which save a new line in database from schema, while init_from_schema only create a new object not saved in db auto.

[sheoak]

Thank you. My implementation is a bit different, I will post it soon, I have 98% coverage with bdd test for now. I removed a lot of the initial repository and moved the all CRUD part into the model and pydantic schema.

[sheoak]

@scil : It's still a work in progress and I will refactor a lot of stuff, but if you are interested you can check my new repository based on full-stack-fastapi-postgresql backend. I just used the regular sqlalchemy-mixins without any modification.

https://github.com/sheoak/fastapi-backend/blob/master/app/models/user.py

[hamzaahmad-io]

I'm wondering if the post that I've created should really be combined with this issue. I had a very similar question and posted here: #241 Any thoughts?

[sheoak]

I'm wondering if the post that I've created should really be combined with this issue. I had a very similar question and posted here: #241 Any thoughts?

Yeah, it seems it respond to the same concern, but with a different method. Have you been testing your implementation, any feedback?

[scil]

@scil : It's still a work in progress and I will refactor a lot of stuff, but if you are interested you can check my new repository based on full-stack-fastapi-postgresql backend. I just used the regular sqlalchemy-mixins without any modification.

https://github.com/sheoak/fastapi-backend/blob/master/app/models/user.py

sqlalchemy-mixins does not support Coroutine，it can not differentiate multiple db sessions across multiple requests.

it does not fit fastcgi,

please consider https://github.com/scil/sqlalchemy-mixins-for-starlette.

[sheoak]

sqlalchemy-mixins does not support Coroutine，it can not differentiate multiple db sessions across multiple requests.

Ah… I noticed some errors that I haven't investigate yet, maybe it's related. Instance <Document at […]> is not bound to a Session; attribute refresh operation cannot proceed

Thanks for your comment, very helpful.