3 ms·
Some people want to replace the ORM, but I find myself dropping into SQL in places where I need more advanced features. Django is sometimes chided for its simpl
by gtaylor 12y ago
Some people want to replace the ORM, but I find myself dropping into SQL in places where I need more advanced features. Django is sometimes chided for its simplistic ORM, but I've actually started thinking that if you are going to use an ORM at all, it probably should only be used for the more simple cases. Fortunately, the vast majority of queries in our codebase at Pathwright are pretty simple.
You need not be afraid to use SQL when you need to do something more advanced. You don't need to feel dirty about it. Postgres in particular can do many more things than any ORM is going to be able to cover 100%. Sometimes you can flat out do something much more efficiently than the ORM can with a simple SQL statement.
If you follow this line of thinking, I'm not sure there's a great reason to bother wedging SQLAlchemy into Django, if I'm just going to end up dropping down into SQL for the more advanced queries.
- wahnfrieden 12y agoThe ORM lets you write raw SQL with .extra: https://docs.djangoproject.com/en/dev/ref/models/querysets/#extra https://docs.djangoproject.com/en/dev/ref/models/querysets/#... and still get ORM objects back in return, or with .raw: https://docs.djangoproject.com/en/dev/topics/db/sql/ https://docs.djangoproject.com/en/dev/topics/db/sql/ or just by manipulating cursors directly. Nothing in Django makes it harder to use raw SQL...
- raverbashing 12y agoI agree, sure, you lose portability (or you can have a generic slower ORM case if it's that important) but dropping down to the SQL in corner cases is perfectly valid (and helpful)
- gtaylor 12y agoFor many cases, portability is a complete non-issue. For example, at Pathwright we chose Postgres for a bunch of reasons. We don't care about MySQL or Oracle or SQL Server. If there ever came a point where we had to make a switch for some reason, it wouldn't be horrible to make the necessary changes to the smaller number of places that we use SQL. Of course, portability could be more of a concern if you are writing something that you are going to let customers run on their own hardware/environment. Though even then, I'm not sure I'd want to have to deal with supporting customers using every DB server that Django supports...