41–50 of 84 posts
> Currently maintained external dialect projects for SQLAlchemy include: [...]
Is there a list of async [SQLA] DB adapters?
The SQLAlchemy 2.0 Release Docs: https://docs.sqlalchemy.org/en/20/orm/extensions/asyncio.htm...
Less is more.
Non-blocking I/O is wonderful news though, especially for high throughput yet high latency internet native databases such CockroachDB.
I was just working on sqlalchemy. zzzeek's help if you get stuck somewhere is outstanding. Async is a godsent feature for us.
Out of curiosity, what's the benefit of async for you?
I would urge people who have had issues with the documentation to give the 2.0 documentation a try. Many aspects of it have been completely rewritten, both to correctly describe things in terms of the new APIs as well as to modernize a lot of old documentation that was written many years ago. First off, SQLAlchemy's docs are pretty easy to get to, for a direct link just go to: https://docs.sqlalchemy.org/ It's an eso…
>>> 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
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)
it's breaking zen of python, it makes searching examples on Google very hard ( esp with Google getting really crappy)
Sorry for detracting from the release news but SQLAlchemy has to have the least helpful website of any major library I can think of. I'm trying to find basic 101 code examples and it's just one wall of text after another. I found how to cite SQLAlchemy in a research paper and have yet to find a single code example.
Check out pugsql, we switched from SQLAlchemy to that because the former was overkill, and way too complex.
Earlier quoted context omitted.
I find ORM models useful for type checking and migrations, what is your experience for this with pugsql?
At the risk of sounding flippant (which I promise is not the intention), if I care about type safety I don’t use python.
Sorry for detracting from the release news but SQLAlchemy has to have the least helpful website of any major library I can think of. I'm trying to find basic 101 code examples and it's just one wall of text after another. I found how to cite SQLAlchemy in a research paper and have yet to find a single code example.
Yes, that's probably my biggest complaint about the library. The docs are there but hard to navigate. Sometimes crucial tips are buried in an aside on one of the many pages that talk about the same topic. It's difficult to get started and it's also difficult to find the ultimate explanation of what's going on.
For a decade I avoided sqlalchemy, we finally got to use it last year and found it quite overwhelmingly complex and 1.4 documentation is messy. We had to use mixed styles. I checked unified doc and it had improved but , still wall of texts.. quite hard to read. Readability count's.
What do you use instead?
And now finding sqlalchemy 2.0 still way too complicated
And it should become default go-to doc for every new comers
I would urge people who have had issues with the documentation to give the 2.0 documentation a try. Many aspects of it have been completely rewritten, both to correctly describe things in terms of the new APIs as well as to modernize a lot of old documentation that was written many years ago. First off, SQLAlchemy's docs are pretty easy to get to, for a direct link just go to: https://docs.sqlalchemy.org/ It's an eso…
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: ... re…
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.