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

71–80 of 84 posts

Re: SQLAlchemy 2.0 Released

#71

Post by zzzeek »

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 ?

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

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

that's the only style we would have if we were starting now.

Re: SQLAlchemy 2.0 Released

#72

Post by zzzeek »

elephantum wrote: post #53
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…

Just want to thank you for all the work you do! We are heavy users of sqlalchemy, our life would be much harder without it!

youre welcome, glad it is of help

Re: SQLAlchemy 2.0 Released

#73

Post by epgui »

v3ss0n wrote: post #46
epgui wrote: post #39

Earlier quoted context omitted.

At the risk of sounding flippant (which I promise is not the intention), if I care about type safety I don’t use python.

Why? Python 3.8+ have perfect typing

Simply because other languages such as haskell are much, much better at that.

Re: SQLAlchemy 2.0 Released

#74

Post by remram »

deaddodo wrote: post #31
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?

Alembic is the most common tool paired with SQLAlchemy.

Alembic is great. It will generate most schema changes from your updated models' code. I even use it programmatically in one app, to automatically migrate the SQLite database on the user's machine, and it has been extremely reliable.

Re: SQLAlchemy 2.0 Released

#75

Post by remram »

geenat wrote: post #42

Wall of text. Less is more. Non-blocking I/O is wonderful news though, especially for high throughput yet high latency internet native databases such CockroachDB.

"internet native" is such a BS term. How has the rest of the internet survived this long, without their "native" tool...

Re: SQLAlchemy 2.0 Released

#76

Post by wpwpwpw »

just want to thank the developers and community for their amazing effort. i just started webdev in python (which i did not previously used) and sqlalchemy's docs are amazing. again, thank you!

Re: SQLAlchemy 2.0 Released

#77

Post by kerkeslager »

remram wrote: post #74
deaddodo wrote: post #31

Earlier quoted context omitted.

Alembic is the most common tool paired with SQLAlchemy.

Alembic is great. It will generate most schema changes from your updated models' code. I even use it programmatically in one app, to automatically migrate the SQLite database on the user's machine, and it has been extremely reliable.

I tried Alembic a long time ago, and it was a bit unstable then, but it was long enough ago that I seem to remember it being new, so maybe it's fixed up now. I'll give it another look.

Re: SQLAlchemy 2.0 Released

#78

Post by inquirer39243 »

zzzeek wrote: post #69
inquirer39243 wrote: post #29

Earlier quoted context omitted.

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…

Oh yeah I love it!

I don't know why but it's just way more intuitive this way for me at least, thanks!

Re: SQLAlchemy 2.0 Released

#79

Post by travisjungroth »

Spivak wrote: post #67
BerislavLopac wrote: post #61

Earlier quoted context omitted.

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?

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

Re: SQLAlchemy 2.0 Released

#80

Post by aflukasz »

Congratulations!

Given how popular SQLAlchemy is, I wonder how many projects are going to wake up on Monday with failing tests (or production) due to not pinning versions and ignoring deprecation warnings...

Post reply on HN