Earlier quoted context omitted.
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…
> 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.
SQLAlchemy 2.0 Released
51–60 of 84 posts
Re: SQLAlchemy 2.0 Released
#52Earlier quoted context omitted.
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…
> 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.
Re: SQLAlchemy 2.0 Released
#53I 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…
Re: SQLAlchemy 2.0 Released
#54Earlier quoted context omitted.
> 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.
Then one really simple question: what to use ?
Re: SQLAlchemy 2.0 Released
#55Re: SQLAlchemy 2.0 Released
#56Earlier quoted context omitted.
If you are doing ORM on a greenfield project, the declarative style.
Which declarative style? Mapped or columns?
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.
Re: SQLAlchemy 2.0 Released
#57Earlier quoted context omitted.
When I see such a poor website, I also expect the codebase to be clunky and cluttered. Better alternative: - https://pugsql.org/
I've worked for close to a decade with Django's ORM and recently with TypeORM, both have been simple to use and generally (minus some weird things I tried to do) a pleasure. I recently started working with a not so important project at my current job with sqlalchemy because I had to use Flask, I cannot describe the pain I've felt working with this, I dread having to write yet another query with sqlalchemy. The docs a…
Thats Exactly my experience using SqlAlchemy on previous project , which i choose to do with Starlite framework. The pain is horrible. I don't want to even touch writing another query , even if it is a simple CRUD .
>However, even if the docs are good the API is still the worst and least intuitive I've ever seen, it honestly feels like I'm writing raw sql code shaped like python code. But it is weird, non standard and difficult to follow, unlike the official python sql interface. I recently had to write an upset and it felt like I was trying to summon a forgotten demon. It would have honestly been much easier to just write it in raw sql.
At this point , only DjangoORM is fun , and even raw SQL is a lot more fun than SQLAlchemy .. I had looked into docs and it seems that not much is improved. API still have many ways to do a single thing , returning a bit different results .
I don't understand why Python Community embrace SQLAlchemy and touted it as best ORM in the world , while it breaks all the Zen of python. Even plain old SQL statements are closer to Philisophy of python.
pugsql looks a lot of fun but when i checked the last commit , it was almost a year ago..
Re: SQLAlchemy 2.0 Released
#58Earlier quoted context omitted.
When I see such a poor website, I also expect the codebase to be clunky and cluttered. Better alternative: - https://pugsql.org/
This is neat - I'd never heard of it. I've been using psycopg2 directly with a thin layer for managing connections and transactions using thread-locals for a long time - RealDictRow and some adapters for jsonb and a few other types make it really easy to work with.
Re: SQLAlchemy 2.0 Released
#59Re: SQLAlchemy 2.0 Released
#60Earlier quoted context omitted.
What do you use instead?
Now we're using Django for current project. But for new project we planned to use Starlite framework so we are still deciding 1. PicoloORM 2. Sqlalchemy 2.x And now finding sqlalchemy 2.0 still way too complicated