4 ms·
So confused after reading unified tutorial. It's so confusing and too many styles to declare ORM >>> class User(Base): ... __tablename__ = "user_account"
by v3ss0n 4y ago
So confused after reading unified tutorial.
It's so confusing and too many styles to declare ORM
>>> class User(Base):
... __tablename__ = "user_account"
...
... id: Mapped[int] = mapped_column(primary_key=True)
... name: Mapped[str] = mapped_column(String(30))
... fullname: Mapped[Optional[str]]
...
... addresses: Mapped[List["Address"]] = relationship(back_populates="user")
...
... def __repr__(self) -> str:
... return f"User(id={self.id!r}, name={self.name!r},
VS
class User(Base):
__tablename__ = "user_account"
id = mapped_column(Integer, primary_key=True)
name = mapped_column(String(30), nullable=False)
fullname = mapped_column(String)
addresses = relationship("Address", back_populates="user")
# ... definition continues
Vs
user_table = Table(
"user",
mapper_registry.metadata,
Column("id", Integer, primary_key=True),
Column("name", String(50)),
Column("fullname", String(50)),
Column("nickname", String(12)),
)
Vs
class Customers(Base):
__tablename__ = 'customers'
id = Column(Integer, primary_key = True)
name = Column(String)
address = Column(String)
email = Column(String)
Why so many styles? Why can't be like pydantic or Django and use just one style for ORM?
it's breaking zen of python, it makes searching examples on Google very hard ( esp with Google getting really crappy)
- dragonwriter 4y ago> Why can't be like pydantic Pydantic also has multiple styles, in fact, I think it has more styles than SQLAlchemy. > and use just one style for ORM? To be fair, one of the “styles” you show is not ORM, its the lower-level Core which can be used without the ORM and which the ORM is built on top of. And the two ORM styles include an older one largely for backward compatibility and a more modern one.
- deleted 4y ago[deleted]
- v3ss0n 4y agoThen one really simple question: what to use ?
- dragonwriter 4y agoIf you are doing ORM on a greenfield project, the declarative style.
- v3ss0n 4y agoWhich declarative style? Mapped or columns?
- zo1 4y agoColumns. 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 agoMy 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 agoSo build your own application-specific bespoke ORM from dataclasses rather than using the one sitting right there?
- travisjungroth 4y ago
- zzzeek 4y agoI can't see the difference between the first two "VS" examples you have above, it just looks like they are formatted differently (oh, one has annotations and the other doesn't. you'd use the annotated version. I guess you are cut-and-pasting from a migration guide that's for legacy code. "migration guide" means "I have legacy code". if you don't have legacy code, you have nothing to migrate. Go straight to https://docs.sqlalchemy.org/en/20/orm/quickstart.html https://docs.sqlalchemy.org/en/20/orm/quickstart.html ). The second example is a Core table. The new tutorial makes it clear that this is an underlying element that nonetheless you have to sometimes create directly. the third example is gone. That style is not in the docs anymore *except* in a clearly marked side-box that is talking about a legacy version of SQLAlhcemy - you don't have to read that and the box IMO makes it as clear as it can that this is not the current way of doing things. > Why so many styles? Why can't be like pydantic or Django and use just one style for ORM? pydantic is extremely new and SQLAlchemy's declarative style pre-dates Python 3 entirely. So we have changed it. The old ways of doing things have to be maintained for backwards compatibility with millions of existing applications. You can't be around for 16 years and have exactly one way of doing things that never changes, legacy patterns for large software libraries are a fact of life. as for django I dont know what they are doing, I am sure things had to change for them to accommodate pep-484 typing in models (if they have even done that).