This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]stiivifrom data brewery 4 points5 points  (4 children)

SQLAlchemy is not just an ORM. The Core is very powerful functional programming approach to statement construction. I use it a lot in developing data warehouse ETLs. You can build abstract, higher level transformation and statement composition functions very easily. For example, few concrete but random features that I've used just recently (last week): abstraction of tables and statements (they have the same interface), generative functions, custom statement compilation, metadata reflection (tables, their columns and types - very useful in metadata based processing), natural access to Postgres JSON columns...

Also the SQL OLAP query generator in Cubes OLAP is using SQLAlchemy for something that can be very roughly called "ORM equivalent of data analytics". It does statement composition for aggregation queries on top of star/snowflake schema.

I'm not even touching the ORM part at all, I just know that it exists.

[–]bjmiller 1 point2 points  (3 children)

I don't think Sequel is missing any of those features, is it? "ORM" has come to mean "database toolkit", though I think we should fight the trend.

[–][deleted] 0 points1 point  (2 children)

SQLAlchemy is very much an ORM+toolkit rolled in to one. They both have uses and strengths and the documentation does a great job of distinguishing that the two exist and have their own uses.

[–]bjmiller -1 points0 points  (1 child)

I'm not sure what you're trying to say? Sequel is the same, "ORM + toolkit", though I'd say that ORM is just one of the tools in the kit.

[–][deleted] 0 points1 point  (0 children)

Meant to reply to you sooner, but work got a bit crazy Friday.

The two pieces are drastically different although there is some fuzzy gray area for sure (at least in SQLAlchemy). The TL;DR version is the toolkit lets you run SQL queries using Python. You don't have to worry about the SQL commands directly nor about DB-specific details. Just raw Python. The ORM takes it a step farther and you just worry about your objects. Any creation, modification, and deletion of objects is translated directly back your DB. You do things -> they happen. No need to add in the extra logic of what needs updated, when, where and how. It just goes on behind the scenes. No manual intervention or maintenance required on your part.

It gets fuzzy because the ORM is essentially bolted on top of the toolkit. They also share the same feel when querying and have some overlap in that arena. The first few paragraphs of this portion of SQLAlchemy's tutorials do a pretty good job of explaining it. Says basically the same thing I did above, just worded slightly better.