5 ms·

I agree with you but I think Sqlalchemy/alembic do the compromises better than Django ORM With Django I always ended up hitting brick walls and ugly hacks. Whe

by smoe 6y ago

I agree with you but I think Sqlalchemy/alembic do the compromises better than Django ORM With Django I always ended up hitting brick walls and ugly hacks. Whereas Sqlalchemy more easily fit in any use case that I had over the years, mainly because of it having multiple layers of abstraction so I can choose and mix as applicable. Learning curve is a bit steeper i admit. I haven't used Sqlalchemy drop in replacement for Django ORM yet, but would consider it for a future project.

hogFeast 6y ago
I think one issue with SQLAlchemy is that, somehow, they are the worst of all worlds. They have multiple ways to run queries (iirc, the "model" way, the non-model way, and the raw way) but it is all the "model" way underneath so you end up with all kind of weird hacks if you don't want to use Python as the source of truth (i.e. if you run a query, have no data model in Python but want to turn the data into a dictionary). It seemed like a very flabby codebase (i.e. they started out doing X, and tried to add stuff on top...lots of classes that appear to do the same thing). The only ORM that I have used that handled more complex stuff well was Jooq (Java). Having your database as the source of truth (and running a script to update Java Objects) works far better than the SQLAlchemy approach. I use Django now for a simple app but I used both Jooq and SQLAlchemy on something more complex (the issue was references to parts of the data models across components), and the former was brilliant (although learning curve) and the latter was just awful. I don't think SQLAlchemy docs are good either (again, started out as X and they just kept adding and adding). That is just my experience. I used Django right now, there are no crazy cross-cutting concerns between components, and it works fine.
- jordic 6y ago
  That's the nice thing around sqlalchemy, it's a lib, a toolkit.. you can start using it on whatever postgresql schema you found.. Django can't only work if things are done like it wants... You will also use Django for an old legacy PHP project with postgresql? You can use SA for taking on it.
  - nikisweeting 6y ago
    You can absolutely use Django for an old Php project with PostgreSQL, just fake the initial migrations and it'll pick up right where PHP left off with the same schema.
- smoe 6y ago
  It is the other way around. The ORM sits on top of core, the sql abstraction. This separation is what I like about it, if I know how to do something in SQL I can use the tools sqla provides and it maps very close to 1:1. Or I can use a more ORM driven approach similar to what Django does. I can adapt it over time as the project evolves. But yes to write the queries in Python and not raw strings, you need to have either a Table or ORM Model defined, which you could generate from the database [1]. But I admit, except for some scripts, I have never used it where Python wasn't the source of truth, so don't know what it all involves. I don't know about very old versions of SQLAlchemy, but at least in the last 4.5 years since I'm using it, I have been much happier with it for medium sized projects over any other similar tool in Python I have tried because of this flexibility [1] Edit: Or use reflection to load schema information from the database >>> messages = Table('messages', meta, autoload=True, autoload_with=engine) >>> [c.name for c in messages.columns] ['message_id', 'message_name', 'date']

by smoe 6y ago

hogFeast 6y ago

I think one issue with SQLAlchemy is that, somehow, they are the worst of all worlds. They have multiple ways to run queries (iirc, the "model" way, the non-model way, and the raw way) but it is all the "model" way underneath so you end up with all kind of weird hacks if you don't want to use Python as the source of truth (i.e. if you run a query, have no data model in Python but want to turn the data into a dictionary). It seemed like a very flabby codebase (i.e. they started out doing X, and tried to add stuff on top...lots of classes that appear to do the same thing). The only ORM that I have used that handled more complex stuff well was Jooq (Java). Having your database as the source of truth (and running a script to update Java Objects) works far better than the SQLAlchemy approach. I use Django now for a simple app but I used both Jooq and SQLAlchemy on something more complex (the issue was references to parts of the data models across components), and the former was brilliant (although learning curve) and the latter was just awful. I don't think SQLAlchemy docs are good either (again, started out as X and they just kept adding and adding). That is just my experience. I used Django right now, there are no crazy cross-cutting concerns between components, and it works fine.

jordic 6y ago
That's the nice thing around sqlalchemy, it's a lib, a toolkit.. you can start using it on whatever postgresql schema you found.. Django can't only work if things are done like it wants... You will also use Django for an old legacy PHP project with postgresql? You can use SA for taking on it.
- nikisweeting 6y ago
  You can absolutely use Django for an old Php project with PostgreSQL, just fake the initial migrations and it'll pick up right where PHP left off with the same schema.
smoe 6y ago
It is the other way around. The ORM sits on top of core, the sql abstraction. This separation is what I like about it, if I know how to do something in SQL I can use the tools sqla provides and it maps very close to 1:1. Or I can use a more ORM driven approach similar to what Django does. I can adapt it over time as the project evolves. But yes to write the queries in Python and not raw strings, you need to have either a Table or ORM Model defined, which you could generate from the database [1]. But I admit, except for some scripts, I have never used it where Python wasn't the source of truth, so don't know what it all involves. I don't know about very old versions of SQLAlchemy, but at least in the last 4.5 years since I'm using it, I have been much happier with it for medium sized projects over any other similar tool in Python I have tried because of this flexibility [1] Edit: Or use reflection to load schema information from the database >>> messages = Table('messages', meta, autoload=True, autoload_with=engine) >>> [c.name for c in messages.columns] ['message_id', 'message_name', 'date']