3 ms·

I kind of wish some of the SQLAlchemy core devs spent a bit of time using ActiveRecord to appreciate how an ORM can make defining and querying relations straigh

I kind of wish some of the SQLAlchemy core devs spent a bit of time using ActiveRecord to appreciate how an ORM can make defining and querying relations straightforward and easy. Right now, using SQLAlchemy creates a "now you have two problems" kind of workflow: first you figure out the SQL need, then you spend at least that long figuring out how to write it with the ORM. I never felt this way about ActiveRecord.

michelpp 6y ago
> I kind of wish some of the SQLAlchemy core devs spent a bit of time using ActiveRecord to appreciate how an ORM can make defining and querying relations straightforward and easy. The main SQLA developer, and the whole team, has been doing this now for almost 3 decades, has presented on and had thousands of serious detailed technical discussions on the subject with a diverse range of industry participants, and I can assure you is WELL aware of how ActiveRecord works and all of the patterns around it.
- qbasic_forever 6y ago
  And? Is it a documentation problem then, that the SQL alchemy devs don't think it's worth the time to explain to devs familiar with active record what they gain using SQLA?
  - zzzeek 6y ago
    you get to think in terms of SQL and relational algebra is the basic idea. Here's one of my talks that discusses this: https://www.sqlalchemy.org/library.html#handcodedapplicationswithsqlalchemy https://www.sqlalchemy.org/library.html#handcodedapplication... as for "it's hard to translate from SQL to ORM" that's a huge part of what 1.4/2.0 is trying to make more obvious. But to be fair I get very few "how do I write this in SQL" questions these days as things are pretty 1-1 in any case now; the remaining weak spots (awkwardness with unions, support for table-valued expressions) are addressed in 1.4/2.0 and the relatively awkward "session.query()" model is now legacy.
  - michelpp 6y ago
    Search "sqlalchemy activerecord" and you will find tutorials, compare and contrast posts, pros and cons, and several implementations for sqlalchemy and many other languages and libraries using the activerecord pattern. SQLAlchemy, and Python in general, is highly extensible, it can do the ActiveRecord pattern and many other patterns depending on the data, not just the needs of a content publication system. Here's a couple random AR/SQLA implementations I plucked from DDG: https://pypi.org/project/sqlalchemy-mixins/ https://pypi.org/project/sqlalchemy-mixins/ https://pypi.org/project/Flask-ActiveRecord/ https://pypi.org/project/Flask-ActiveRecord/
luhn 6y ago
Honestly that’s my favorite part about SQLAlchemy—you need to think in SQL. It doesn’t try to hide anything behind leaky abstractions, it’s WYSIWYG. Just gives us the good parts of an ORM while sidestepping the whole “ORMs are the Vietnam of Computer Science” problem.
sirn 6y ago
I think this is fundamental design difference between SQLAlchemy and ActiveRecord in general. SQLAlchemy uses Data Mapper pattern which does not necessary map 1:1 to the row in the database, so you have to deal with the whole (Object, Mapper, Data) tuple instead of just Object in case of Active Record pattern (of which Rails' ActiveRecord were based on). This means SQLAlchemy does not try to hide away SQL, which is beneficial in dealing with complex queries. In Rails ActiveRecord you could use arel in such case but being a query builder it lose the benefit of ActiveRecord, whereas in SQLAlchemy it could be done relatively easily within the ORM layer (arel equivalent in SQLAlchemy would be its Expression Language). On the other hand, some things that are complicated in ActiveRecord can also be trivial to implement in SQLAlchemy (e.g., column_property[1]) [1]: https://docs.sqlalchemy.org/en/13/orm/mapped_sql_expr.html https://docs.sqlalchemy.org/en/13/orm/mapped_sql_expr.html
deleted 6y ago
[deleted]

michelpp 6y ago

> I kind of wish some of the SQLAlchemy core devs spent a bit of time using ActiveRecord to appreciate how an ORM can make defining and querying relations straightforward and easy. The main SQLA developer, and the whole team, has been doing this now for almost 3 decades, has presented on and had thousands of serious detailed technical discussions on the subject with a diverse range of industry participants, and I can assure you is WELL aware of how ActiveRecord works and all of the patterns around it.

qbasic_forever 6y ago
And? Is it a documentation problem then, that the SQL alchemy devs don't think it's worth the time to explain to devs familiar with active record what they gain using SQLA?
- zzzeek 6y ago
  you get to think in terms of SQL and relational algebra is the basic idea. Here's one of my talks that discusses this: https://www.sqlalchemy.org/library.html#handcodedapplicationswithsqlalchemy https://www.sqlalchemy.org/library.html#handcodedapplication... as for "it's hard to translate from SQL to ORM" that's a huge part of what 1.4/2.0 is trying to make more obvious. But to be fair I get very few "how do I write this in SQL" questions these days as things are pretty 1-1 in any case now; the remaining weak spots (awkwardness with unions, support for table-valued expressions) are addressed in 1.4/2.0 and the relatively awkward "session.query()" model is now legacy.
- michelpp 6y ago
  Search "sqlalchemy activerecord" and you will find tutorials, compare and contrast posts, pros and cons, and several implementations for sqlalchemy and many other languages and libraries using the activerecord pattern. SQLAlchemy, and Python in general, is highly extensible, it can do the ActiveRecord pattern and many other patterns depending on the data, not just the needs of a content publication system. Here's a couple random AR/SQLA implementations I plucked from DDG: https://pypi.org/project/sqlalchemy-mixins/ https://pypi.org/project/sqlalchemy-mixins/ https://pypi.org/project/Flask-ActiveRecord/ https://pypi.org/project/Flask-ActiveRecord/

luhn 6y ago

Honestly that’s my favorite part about SQLAlchemy—you need to think in SQL. It doesn’t try to hide anything behind leaky abstractions, it’s WYSIWYG. Just gives us the good parts of an ORM while sidestepping the whole “ORMs are the Vietnam of Computer Science” problem.

sirn 6y ago

I think this is fundamental design difference between SQLAlchemy and ActiveRecord in general. SQLAlchemy uses Data Mapper pattern which does not necessary map 1:1 to the row in the database, so you have to deal with the whole (Object, Mapper, Data) tuple instead of just Object in case of Active Record pattern (of which Rails' ActiveRecord were based on). This means SQLAlchemy does not try to hide away SQL, which is beneficial in dealing with complex queries. In Rails ActiveRecord you could use arel in such case but being a query builder it lose the benefit of ActiveRecord, whereas in SQLAlchemy it could be done relatively easily within the ORM layer (arel equivalent in SQLAlchemy would be its Expression Language). On the other hand, some things that are complicated in ActiveRecord can also be trivial to implement in SQLAlchemy (e.g., column_property[1]) [1]: https://docs.sqlalchemy.org/en/13/orm/mapped_sql_expr.html https://docs.sqlalchemy.org/en/13/orm/mapped_sql_expr.html

deleted 6y ago

[deleted]