The thing that makes annoyed is this high level of abstraction of the Django ORM.
I become mad when see things like that:
A.objects.values('b__Bcol1','c__Ccol1','c__Ccol2') , and other queries.
Because I always used to think about the performance , SQL joins and subquerie, I’m sorry to say that but I hated the orm queries.
(I’m okay with creating models.py, my problem is the queries)
My question is:
Is it acceptable by the community and jobs to do (50% raw SQL or maybe more instead of orm) or I need to switch to another languages or framework that accept that ?
Thanks
And if there are any advice for that situation , I will be happy to listen to it
Preferences aside, it’s easy to forget that the ORM actually solves problems. You likely need a query builder pattern. You likely don’t want to worry about sql injection. You likely need to map database rows to python objects.
I’d say it’s idiomatic in Django projects for most sql usage to go through the ORM. I’d also say it’s idiomatic to find raw sql usages when use cases don’t fit the ORM, but it’s much less frequent. The great thing about Django is it’s flexible enough to handle these cases when needed.
Ultimately if it’s your own project do whatever you want. If you’re working on a team, follow your team’s conventions.
Django is just a tool. I personally think you should drop your biases and be open to learning a new tool. After some time, if you don’t like Django, go find a tool that you enjoy working with and at least you will have learned something new.
Well ORM was created so that user does not have to handle complex queries and I think it is easier to configure modely.py that way, but if you are having problem in orm you could use connection from django.db for raw sql queries or just use .raw() method.
I’ve been working with databases since 1981, and I’ve been using SQL since 1986. As far as I’m concerned, the ORM is not a “higher” layer of abstraction than any other querying language.
Never forget that SQL itself is a high level abstraction, being a declarative language and not a procedural language.
In all cases, you’re not writing code that is being executed by the database engine. You’re identifying a set of constraints to define a desired set of results. It’s up to the database engine to figure out how to retrieve those results in the most efficient manner. (You’re specifying what you want rather than how to get it.)
The only way you can properly evaluate the relative performance of two queries is to use something like EXPLAIN ANALYZE. You are not going to be able to just look at two queries and say that one is better than another without considering a number of other factors.
I can’t speak for the community at large, but I can say that Django project code that doesn’t display comfort with using the ORM wouldn’t pass any code review that I’m a part of.
Nor do I think that you will find any significant percentage of Django-based Open Source projects that don’t rely upon the ORM.
Is the ORM “perfect”? No. There still are some things that are difficult-to-impossible. (But that list continues to shrink over time as improvements continue to be made.)
So yes, there are cases where using the ORM isn’t appropriate or practical, but in my experience, they tend to be rare and fairly well defined. (e.g. Integrating a schema created by a legacy system with a Django-based front-end, where that schema is not designed well.) I can only think of two systems that I have worked on over the past 12 years where it has been necessary or desirable to work around the ORM rather than working with it.
I just merged an improvement to the “Performing raw sql queries” document that describes how to embed raw SQL fragments into ORM queries, so that you don’t have to completely eject yourself from the ORM
I just merged an improvement to the “Performing raw sql queries” document that describes how to embed raw SQL fragments into ORM queries, so that you don’t have to completely eject yourself from the ORM
TIL
Thank you for sharing and improving the documentation!
It sounds to me like you don’t really want to use Django - the ORM happens to be one of the most important and useful abstractions in the entire framework.
having a 50% split between raw sql and orm usage will just increase the complexity of your codebase. Your data access layer will be spread across two different abstractions and mental models. While the django orm is well tested, you will almost undoubtedly need to create further abstractions for the 50% of code that isn’t orm related; This will necessitate more testing and add more surface area for bugs.
“Nothing is forbidden, Everything is permitted” but as others have mentioned in this thread, this is an anti pattern in Django. I don’t recommend it.
