Return original ORM instead of dict/pydantic?

[Abufari]

I'm not terribly experienced with CRUD operations using pydantic, but my understanding so far has been that the service layer returns the ORM, which you can either use for some further internal computation, or FastAPI will turn it into a Pydantic model to return in the endpoint. Now FastCRUD seems to short-circuit it by returning a dict or pydantic model directly, but never the original model. That's alright if you want to return it in the endpoint anyway, but might be limiting its use for internal handling.

Is that not one of the intended usages of FastCRUD? If not, why not? Do I have to do the manual join and filtering again myself if I want the ORM?

[igorbenav]

Hey, @Abufari!
The thing is I don't know a way to query only some fields and return a model.

If I have a user table:

from sqlalchemy import Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)
    # other fields...

And only want to get name and id, I can do it by querying directly with sqlalchemy, but it will return row objects:

result = session.query(User.id, User.name).filter(...).all()

This returns a list of Row objects, not User model instances.

If we used a sqlalchemy model, we would have to query the whole thing:

users = session.query(User).filter(...).all()

This fetches all columns, which makes it less efficient (specially for many columns or columns with a large memory footprint

[igorbenav]

An option would be adding a return_as_sqlalchemy_model or something like it, but only working when a schema is not passed. This would probably involve rewriting a lot of the code, since everything kind of expects Row objects (and the way the queries are written, we always get Row objects as a result)

[Abufari]

Hi @igorbenav
Thanks for taking the time to answer. I definitely wouldn't suggest any changes to the code, because I'm not in the position to say if it's really necessary to get the SQLalchemy model, it's just that this has been my workflow so far and it made sense to me. Also, to be honest, I always selected the whole model, and not just individual columns, so I didn't have to work with Rows so far. The pydantic models will convert it afterwards for me.
I'm just curious if there are downsides when not working with the sqlalchemy model directly? I'm thinking about direct changes to some columns that are easier to commit than this pydantic back and forth, which is really meant for serializing to and from the outside.