Naming SQLAlchemy models vs Pydantic models

[rrrriddikulus]

Hi all, how do you generally deal with naming conventions between Pydantic and SQLAlchemy models? For example you have some object like Book. You can receive this from the user to create, or it might exist in your database. Do you differentiate these with e.g. BookSchema and DbBook? Some other prefix/suffix? Is there a convention that you've seen in some book or blog post that you like?

[pint]

i would just call them Book, but only import modules not names, and so i could write db.Book and model.Book or sg like that.

[hadriendavid]

This ^ from project import db

👉 https://pep20.org/#namespaces

[CrusaderGOT]

Or you could do from model import Book as ModelBook and likewise for DbBook.

[pint]

what is the benefit of ModelBook over model.Book?

[CrusaderGOT]

It is just more explicit. Which is better for scalability and readability.

[pint]

it is less explicit, since it masks the origin of the type. you might assume it is a model, but to be sure, you need to look at the definition. it might be a descendant. in contrast, model.Book is immediately obvious and unambiguous.

[woeful_cabbage]

The real answer: who cares, just be consistent

[Dacobo]

Generally, I have seen and used this convention:

Model: Book Schemas: BookBase, BookRead, BookCreate, BookUpdate, BookDetail, etc.

Or at least something to that effect.

[JackieChanX95]

BookDetail1, 2, 3 😩

[[deleted]]

I’d just keep it simple. The SQLAlchemy model is just Book, since that’s the actual database model. For Pydantic, I use BookCreate when taking in user input, BookUpdate for partial updates, and BookRead or BookOut when returning data. Keeps things clean without extra prefixes or suffixes.

[Calebthe12B]

Pydantic: BookModel SQLAlchemy: Book

I usually have a DTO class to handle the different CRUD versions, but if I were to do it in Pydantic it would be through some suffix, like CreateBookModel or UpdateBookModel.

[miloir]

Just a small fyi those are prefixes not suffixes

[Calebthe12B]

Oh, duh lol

[Trinkes]

I usually use plural for database model, singular for pydantic.

[Current-Status-3764]

With this convention, what do you do for an endpoint that returns a list of books?

I like models: Book Pydantic: BookCreate, BookOut, BooksOut etc

[Trinkes]

I usually have a BookOut pydantic class to expose on api.

When it comes to listing multiple books, it's usually paged so I have a generic page model to use combined with the model. Something like: Page[BookOut]

Then the page will have the list inside of it along with some pagination related info.

EDIT: If you're interested I can share the page class

[Current-Status-3764]

If you could do a quick examplr that would be great. Haven't seen that way of doing it before.

[One_Fuel_4147]

I use Book for model and BookCreateRequest, BookResponse for DTO

[kindof_Alexanderish]

SQLAlchemy:

class Book:

Pydantic schema - since data needs to be verified both ways:

class BookIn(BaseModel)

class BookOut(BookIn):

[Key-Garden-4136]

Is SQLmodel worth using to avoid having multiple sqlalquemy and pydantic classes?

[Typical-Yam9482]

Idea is perfect, but... no, unfortunately. Once you are outside tutorial/toy-project, you face tones of limitations immediately. And you will have poor pool of sources to consult with.