I didn't understand why ORMs are stupid. Can someone enlighten me?
I guess his point is that they sometimes create huge ugly and inefficient SQL queries. (Reminds me of the 90s sentiment of C compilers creating ugly assembly.)
Lessons learned defying Joel Spolsky with Django
61–70 of 155 posts
Re: Lessons learned defying Joel Spolsky with Django
#62Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?
"what advantage does Django provide at this point in this project anymore?" Documentation. I use Django but without any ORM and with Jinja2, so it's basically just Flask but with more stack overflow threads and more third-party software. Is there any actual advantage that I would be getting by using Flask instead?
The advantages aren't really in using Flask, but being able to use a better ORM (or no ORM at all, just SQL abstraction) and template engine.
After working with Django ORM for a large project, I started to rethink the usefulness of models. It turns out just treating data as sets lends to a functional style and is simpler down the road.
Re: Lessons learned defying Joel Spolsky with Django
#63While I love seeing slides, this deck obviously could use the audio or transcript along with it.
Agreed, I for one was felt feeling rather in the dark for the last few slides especially...
We are posting a version with audio on our blog on Monday: http://blog.iconfinder.com
Re: Lessons learned defying Joel Spolsky with Django
#64Earlier quoted context omitted.
"what advantage does Django provide at this point in this project anymore?" Documentation. I use Django but without any ORM and with Jinja2, so it's basically just Flask but with more stack overflow threads and more third-party software. Is there any actual advantage that I would be getting by using Flask instead?
I also use Django without any ORM and with Jinja2 and I'm taking baby steps towards completely abandoning Django and moving to Flask. For me, the primary benefit is that Flask being so much smaller and simpler than Django means you can understand the entire codebase without an extraordinary amount of effort. I'm curious as to why you stick with Django (other than having projects already begun relying on it)? Without…
"I'm curious as to why you stick with Django (other than having projects already begun relying on it)?"
I'm still a relatively new developer, so it was just easier to learn.
Re: Lessons learned defying Joel Spolsky with Django
#65Earlier quoted context omitted.
The SQL generated appears correct, unless the underlying database can guarantee that all foreign key constraints are met. That is, I consider this a failure of the user of the ORM to appreciate that the two invocations of filter are not identical. In the former case, the query is verifying that the object_id field cannot be used to find a foreign object--regardless of the value of object_id. This is exactly what it i…
"other_id" and "other" here refer to two different ways of referring to a many-to-one reference between "somemodel" and "othermodel". Asking for rows of "somemodel" where "object_id" is None is the exact same thing as asking for rows from "somemodel" where its reference to "object" is None. Both should produce the same query, the simple one without the JOIN. The query with the JOIN is completely wasteful and not at a…
So the ORM is too stupid to know that in the case the other_id is NULL, it doesn't need to create a join subquery. But would you rather the PostgreSQL query planner figure this out or do it yourself in python? I would like to see the time difference both queries take, and I don't think I would want Django ORM to do this.
Re: Lessons learned defying Joel Spolsky with Django
#66Re: Lessons learned defying Joel Spolsky with Django
#67Earlier quoted context omitted.
Why not just write the SQL?
When ORMs first started becoming popular during the 2000s, especially within the Java world, their proponents drummed up a lot of animosity toward SQL. While a lot of us who had started working with SQL in the 1980s, if not earlier, were perfectly fine with using it, many younger developers were scared away from it by these claims. So we've had a generation of software developers who were essentially raised to hate S…
I don't mind writing queries, but I hate dealing with raw results. For complex queries I write SQL but have Django's ORM map relational data to objects for me.
Re: Lessons learned defying Joel Spolsky with Django
#68Earlier quoted context omitted.
"other_id" and "other" here refer to two different ways of referring to a many-to-one reference between "somemodel" and "othermodel". Asking for rows of "somemodel" where "object_id" is None is the exact same thing as asking for rows from "somemodel" where its reference to "object" is None. Both should produce the same query, the simple one without the JOIN. The query with the JOIN is completely wasteful and not at a…
You're right in that they are largely the same action, but consider this case: An Owner is deleted without setting the pets.owner_id to NULL. So now there's a row in Pets with an owner_id referring to an Owner that doesn't exist. These two queries will (rightfully) return different things in this case. One will return The Pets who have null for an owner_id. The other will return the Pets whose owner_id is NULL AND th…
OK, you're right in that owner_id can refer to a nonexistent entry, if the schema both doesn't make correct use of constraints and is also referentially corrupt. Designing the ORM to jump through huge hoops to suit the case that the user is using the relational database incorrectly, in such a way that enormous performance overhead is added to the use case as used correctly in the vast majority of cases, is IMO a poor design decision.
Re: Lessons learned defying Joel Spolsky with Django
#69Earlier quoted context omitted.
"other_id" and "other" here refer to two different ways of referring to a many-to-one reference between "somemodel" and "othermodel". Asking for rows of "somemodel" where "object_id" is None is the exact same thing as asking for rows from "somemodel" where its reference to "object" is None. Both should produce the same query, the simple one without the JOIN. The query with the JOIN is completely wasteful and not at a…
You're right in that they are largely the same action, but consider this case: An Owner is deleted without setting the pets.owner_id to NULL. So now there's a row in Pets with an owner_id referring to an Owner that doesn't exist. These two queries will (rightfully) return different things in this case. One will return The Pets who have null for an owner_id. The other will return the Pets whose owner_id is NULL AND th…
Great point, I didn't even think of that! The join there is for a reason, and that you're getting the entire 'model' not a field. If someone thinks what ORM does in this case is stupid, they probably think table constraints are stupid.
Re: Lessons learned defying Joel Spolsky with Django
#70Earlier quoted context omitted.
"other_id" and "other" here refer to two different ways of referring to a many-to-one reference between "somemodel" and "othermodel". Asking for rows of "somemodel" where "object_id" is None is the exact same thing as asking for rows from "somemodel" where its reference to "object" is None. Both should produce the same query, the simple one without the JOIN. The query with the JOIN is completely wasteful and not at a…
So the ORM is too stupid to know that in the case the other_id is NULL, it doesn't need to create a join subquery. But would you rather the PostgreSQL query planner figure this out or do it yourself in python? I would like to see the time difference both queries take, and I don't think I would want Django ORM to do this.
I think you should run EXPLAIN ANALYZE on both queries and see what you find.