Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLAlchemy 2.0 Released

sqlalchemy.org

Post reply on HN
Print view View original

61–70 of 84 posts

Re: SQLAlchemy 2.0 Released

#61

Post by BerislavLopac »

v3ss0n wrote: post #52
dragonwriter wrote: post #50

Earlier 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 ?

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.

Re: SQLAlchemy 2.0 Released

#62

Post by manfre »

v3ss0n wrote: post #58
mattbillenstein wrote: post #21

Earlier quoted context omitted.

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.

its dead though.

Most projects stop updating the previous major release.

https://www.psycopg.org/psycopg3/

Re: SQLAlchemy 2.0 Released

#63

Post by robertlagrant »

zzzeek wrote: post #19

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…

This has been a long time coming. Many congratulations.

Re: SQLAlchemy 2.0 Released

#64

Post by robertlagrant »

kerkeslager wrote: post #30

SQLAlchemy's lightweight SQL wrapping was a revelation when I came across it, but I've come to rely a lot on Django's migration tooling, enough so to choose Django for projects. What do people using SQLAlchemy use for migrations?

I just asked ChatGPT "How can I migrate database structures using SQLAlchemy?" and it gave an amazing answer. Alembic with examples.

Re: SQLAlchemy 2.0 Released

#65

Post by Dowwie »

mmerickel wrote: post #37
zzzeek wrote: post #19

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…

SQLAlchemy and your efforts are so amazing and appreciated. Thank you and the team for all of your hard work on 2.0 as well as the heroic effort that was put into 1.4 as a stepping stone for existing codebases!

Hey Mike! :) Hope all is well.

Re: SQLAlchemy 2.0 Released

#67

Post by Spivak »

BerislavLopac wrote: post #61
v3ss0n wrote: post #52

Earlier quoted context omitted.

Then one really simple question: what to use ?

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 ma…

So build your own application-specific bespoke ORM from dataclasses rather than using the one sitting right there?

Re: SQLAlchemy 2.0 Released

#68

Post by zzzeek »

mixmastamyk wrote: post #26
zzzeek wrote: post #19

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…

Great tool. I think this is why folks have trouble finding the docs: Whole entire site is docs everywhere, including home page. Links to "docs" are tiny on the home page. Main menu calls them "library" instead of docs, why? Majority of the stuff is focused on migration rather than new users. These two should be separated into separate tracks immediately. There is an attempt, but it gets lost somehow. Also the release…

> Whole entire site is docs everywhere, including home page. Links to "docs" are tiny on the home page.

you got it, look now. If you can't find the docs now, I dont know what to say.

> Main menu calls them "library" instead of docs, why?

A library is where you'd go to learn...but I guess, because the product is a "library", that's why it's not obvious? The term is gone from the nav etc. the sub-page is still called "library" but nobody needs to go there.

Re: SQLAlchemy 2.0 Released

#69

Post by zzzeek »

inquirer39243 wrote: post #29
zzzeek wrote: post #28

Earlier quoted context omitted.

The link I posted here is the blog post. That's why it's historical and chatty, it's the blog post.

Love your tools! I think you should consider changing "library" to "documentation" - for whatever reason I also struggled to discover "library" actually meant docs - but only after I also clicked on a specific version. I think the best UI/UX for this is something like django's [0], where "documentation" brings you straight to the latest version's documentation. [0] https://www.djangoproject.com/

> I think you should consider changing "library" to "documentation" - for whatever reason I also struggled to discover "library" actually meant docs - but only after I also clicked on a specific version.

you got it, look now

> I think the best UI/UX for this is something like django's [0], where "documentation" brings you straight to the latest version's documentation.

the design of our main docs index page was taken completely from how Django does it (e.g. how they have "paragraphs of links" at https://docs.djangoproject.com/en/4.1/)

Re: SQLAlchemy 2.0 Released

#70

Post by zzzeek »

v3ss0n wrote: post #44
zzzeek wrote: post #19

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…

I 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 ).

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).

Post reply on HN