3 ms·

Then one really simple question: what to use ?

by v3ss0n 4y ago

dragonwriter 4y ago
If you are doing ORM on a greenfield project, the declarative style.
- v3ss0n 4y ago
  Which declarative style? Mapped or columns?
  - zo1 4y ago
    Columns. Even early on many years ago, I ignore all the exotic forms and different ways. Leave those for when you need to do something non-standard or programmatic. Choose a form that works for you and looks nice, apply it to all your oddest use cases like many to many relationships and self-referential relationships, and then use that as a template going forward.
BerislavLopac 4y ago
My recommendation is to avoid using an ORM (SQLAlchemy or any other) to define the business logic models (which is the approach used in Django). That works well only if your business models and your database entities align very closely, but in many large systems this is not the case, end you end up running around in circles trying to align the two. Instead, use either an ORM, or even better the SQLALchemy core, to manage and abstract out the database; and use something like dataclasses, attrs or Pydantic to define your business logic models. In a network-oriented application, i.e. an API, I would recommend to use a separate tool to model the I/O entities, again unless they correspond very closely to the business ones.
- Spivak 4y ago
  So build your own application-specific bespoke ORM from dataclasses rather than using the one sitting right there?
  - travisjungroth 4y ago
    When that pattern is done well, and it can be, it’s that you have a layer that doesn’t care that stuff is stored in a database. It’s lots of logic. That layer uses tools like dataclasses. Then you have some layer that stores things in the database. It’s like a record keeper. It uses an ORM or not. One benefit of this is ORMs are giant, complex objects by necessity. It’s good to only use them where they’re needed, at the database. Then you don’t have all their magic floating through your business code. They’re also rather opinionated. I, at least, experience whay more freedom when making a class from scratch than using an ORM. This comes at a cost of maintaining two versions of lots of things and a translation layer in between. It is overkill for super CRUDy stuff (most apps).
zzzeek 4y ago
the current tutorial and quickstart guide should make it exceedingly clear, how is it that people are still confused? this is the quickstart: https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html that's the one you use. That's it! There is no other style listed there lots of people still want to use other styles or still have to because they have legacy code. So these are documented also. However, SQLAlchemy wants you to use the style at: https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html that's the only style we would have if we were starting now.

Then one really simple question: what to use ?

by v3ss0n 4y ago

Then one really simple question: what to use ?

dragonwriter 4y ago

If you are doing ORM on a greenfield project, the declarative style.

v3ss0n 4y ago
Which declarative style? Mapped or columns?
- zo1 4y ago
  Columns. Even early on many years ago, I ignore all the exotic forms and different ways. Leave those for when you need to do something non-standard or programmatic. Choose a form that works for you and looks nice, apply it to all your oddest use cases like many to many relationships and self-referential relationships, and then use that as a template going forward.

BerislavLopac 4y ago

My recommendation is to avoid using an ORM (SQLAlchemy or any other) to define the business logic models (which is the approach used in Django). That works well only if your business models and your database entities align very closely, but in many large systems this is not the case, end you end up running around in circles trying to align the two. Instead, use either an ORM, or even better the SQLALchemy core, to manage and abstract out the database; and use something like dataclasses, attrs or Pydantic to define your business logic models. In a network-oriented application, i.e. an API, I would recommend to use a separate tool to model the I/O entities, again unless they correspond very closely to the business ones.

Spivak 4y ago
So build your own application-specific bespoke ORM from dataclasses rather than using the one sitting right there?
- travisjungroth 4y ago
  When that pattern is done well, and it can be, it’s that you have a layer that doesn’t care that stuff is stored in a database. It’s lots of logic. That layer uses tools like dataclasses. Then you have some layer that stores things in the database. It’s like a record keeper. It uses an ORM or not. One benefit of this is ORMs are giant, complex objects by necessity. It’s good to only use them where they’re needed, at the database. Then you don’t have all their magic floating through your business code. They’re also rather opinionated. I, at least, experience whay more freedom when making a class from scratch than using an ORM. This comes at a cost of maintaining two versions of lots of things and a translation layer in between. It is overkill for super CRUDy stuff (most apps).

zzzeek 4y ago

the current tutorial and quickstart guide should make it exceedingly clear, how is it that people are still confused? this is the quickstart: https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html that's the one you use. That's it! There is no other style listed there lots of people still want to use other styles or still have to because they have legacy code. So these are documented also. However, SQLAlchemy wants you to use the style at: https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html that's the only style we would have if we were starting now.