Models vs Schemas Discussion

[chainyo]

Hi, the more I use the template, the more I feel like there is a swap between app/schemas and app/models.

Shouldn't models be the API request and response models, and schemas be the database tables and data stuff?

It might be a personal opinion without any interest, but it looks counter-intuitive.

Let me know what you guys think about this, and if we agree, I will push a PR to update all the files. 🤗

@grski @Lolomgrofl

[grski]

From my side - full support. I'm not a big fan of DAOs, so in my usage of the template i've adapted that part to cater to my needs.

However having like models - pydantic and then separete db schemas (mby generated based on models 🤔 like in. sqlmodel (that I think we should adapt once they upgrade to pydantic v2)

But the decision is on @Lolomgrofl who mostly drives the project, let's hear him out :)

[chainyo]

sqlmodel (that I think we should adapt once they upgrade to pydantic v2)

Literally 2 days ago I was about adding SQLModel and saw it's currently stuck with pydantic v1 👍

[grski]

fastapi/sqlmodel#621 check out this discussion or the inital (VERY INITIAL) work i started:
fastapi/sqlmodel#622

[Lolomgrofl]

Hey @chainyo👋🏼

I think this is a really good topic, I personally had a lot of discussions about this topic with different people, and imagine, opinions are different 👀

IMHO, both approaches seem to be acceptable and legit and I would say it comes to the people's habits.
Someone is used to calling DB models models, someone entities, someone schemas, etc. It's just how they learned the stuff and the background they are coming from as well as what phrases are more or less natural/intuitive to them.

I think this a really complex topic and it can go way deeper than this conversation.

E.g. if you check this link https://sqlmodel.tiangolo.com/tutorial/fastapi/multiple-models/

tiangolo is referring to the input Pydantic models as schemas as well and in the FastAPI Swagger you have a notion of schema if you want to check the examples of input/output. So I was following some of those annotations as well.

But in general, I think every approach is fine as long as you stick to one convention and team that you are working with is onboarded with it and everything is 💯 % clear.

@grski DAO layer is totally different story and it's not related to this topic. And I'm curious, I would love to hear your thoughts and what is the thing that you don't like about the DAO layer. Feel free to create a discussion on that topic. Because I find it very useful and it's really nice SOC ( separation of concerns) from the business logic.

[Lolomgrofl]

Hey @chainyo I converted this issue to discussion, I think it makes more sense. Any thoughts on the comment above? 😄

[chainyo]

I took a look at a 6-month-old personal project using sqlalchemy, fastapi and sqlmodel and I used this architecture for organizing categories (e.g. users):

The organization is inspired from this repo fastapi-best-practices

But grouping everything under models.py makes more sense when you use sqlmodel. Example for the users models used for the database and the API (pydantic v1):

from pydantic import BaseModel

from sqlmodel import Field, SQLModel

from .config import FREE_USAGE
from ..core.models import TimestampModel, UUIDModel
from .examples import (
    ex_user_admin_patch,
    ex_user_read,
    ex_user_create,
    ex_user_patch,
)


class UserBase(SQLModel):
    """Users table"""
    email: str = Field(unique=True, nullable=False)
    password: str = Field(nullable=False)
    usage: int = Field(default=FREE_USAGE, nullable=True)
    is_admin: bool = Field(default=False)
    

class User(TimestampModel, UserBase, UUIDModel, table=True):
    """User model"""
    __tablename__ = "users"
    

class UserRead(TimestampModel, UUIDModel):
    """User read model"""
    email: str
    usage: int
    is_admin: bool
    class Config:
        schema_extra = {"example": ex_user_read}
        

class UserCreate(UserBase):
    """User create model"""
    email: str
    password: str
    class Config:
        schema_extra = {"example": ex_user_create}
        

class UserPatch(BaseModel):
    """User patch model"""
    email: str
    usage: int
    class Config:
        schema_extra = {"example": ex_user_patch}
        
        
class UserAdminPatch(BaseModel):
    """User admin patch model"""
    email: str
    is_admin: bool
    class Config:
        schema_extra = {"example": ex_user_admin_patch}


class Token(BaseModel):
    """Token model"""
    access_token: str
    token_type: str
    

class TokenData(BaseModel):
    """TokenData model"""
    username: str = None

So until sqlmodel is updated to pydantic v2, it's not a big deal to change file names 🤗 . Also, sqlmodel isn't mandatory for the template, even if it saves time to build schemas/models by making the perfect glue between the database tables and the API request/response models.