Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons learned defying Joel Spolsky with Django

speakerdeck.com

Post reply on HN
Print view View original

31–40 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#31

Post by memset »

drdaeman wrote: post #27
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

I have always wondered why people have an aversion to stored procedures. They are a programming language in themselves, so you could pass all of your parameters (owner, some_condition, other_condition) into a proc and, depending the logic, return a different cursor to a different query.

Re: Lessons learned defying Joel Spolsky with Django

#32

Post by PommeDeTerre »

Aqueous wrote: post #15
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

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 SQL, and to embrace ORMs, even after it became clear that ORMs do come with some pretty serious trade-offs, and do not necessarily increase productivity.

Not having a solid grasp of SQL, a lot of these developers just don't realize what they're missing out on. I've seen this first-hand many times before. These developers will spent hours upon hours trying to get their ORM to perform a moderately complex query that could be easily written by hand within a few minutes, including any code necessary to perform the query and to retrieve the result. The time and effort expended on these sorts of queries will very quickly negate any time and effort the ORM may have saved for simpler queries. And these moderately-complex or complex queries always arise in real-world software.

I think that education is the only way to really solve this problem, but a lot of developers are quite set against this. Learning SQL isn't that much of an investment, but the returns it offers can be huge.

Re: Lessons learned defying Joel Spolsky with Django

#33

Post by andybak »

nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

In addition to the other replies I have to add - the goddamn Admin. The amount of time it saves me is beyond belief.

Re: Lessons learned defying Joel Spolsky with Django

#34

Post by cdavid »

naithemilkman wrote: post #28
speg wrote: post #12

Does anyone know what tool was used to profile the django app? Looks cool.

If you're talking about the slide that says '87.91% of time spent rendering' then yes, I would like to know too. Annoying that it doesnt have slide numbers to refer to.

it looks like kcachegrind or pycallgraph (https://github.com/gak/pycallgraph).

Re: Lessons learned defying Joel Spolsky with Django

#35

Post by jroseattle »

I was expecting this slidedeck to be a bit more focused on defying Spolsky, and whether or not that was a good decision.

FWIW, I've never bought into Spolsky's vision that re-writing code is poor strategy. Steve Jobs never thought twice about ripping something apart and starting over. If anything, code re-write can be an advantageous position -- you often have a greater understanding of the problems you're intending to solve. When well-executed, it can take the form of heavy refactoring, even when switching languages/platforms.

Re: Lessons learned defying Joel Spolsky with Django

#36

Post by SoftwareMaven »

nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

Completely replacing the template system with Jinja is silly (no idea if this is what they did) since it significantly reduces the value of the Django ecosystem. Far better it to use jinja for your work, but leave the Django templates for Django and all the other apps you integrate to use. I do with Django would reduce their stance on no expressions in the templates. Sometimes it saves a lot of work to just be able to call a function or add two numbers together without needing to build a filter or tag every time.

I've been happy with django-jinja[1] for that purpose. It replaces the context processors so it will load jinja templates if they have a .jinja extension and Django if they are .html. It also includes the django filters in jinja-land.

The ORM is more problematic. I just started a project a couple months ago and thought a lot about ditching the default ORM in favor of SqlAlchemy. I decided not to, for the reason of expedience and, as the TFA mentions, it already leaks. So, I stuck with the Django ORM and will drop to SQL directly if need be (need being defined by the ORM making the code confusing or there being performance hotspots).

1. https://github.com/niwibe/django-jinja

Re: Lessons learned defying Joel Spolsky with Django

#37

Post by zzzeek »

k4st wrote: post #29
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

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 all correct - it does a LEFT OUTER JOIN to the remote table, only to filter on those rows where the remote table has no match; but this is already obvious from whether or not "somemodel.other_id" is NULL.

Re: Lessons learned defying Joel Spolsky with Django

#38

Post by SoftwareMaven »

andybak wrote: post #33
nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

In addition to the other replies I have to add - the goddamn Admin. The amount of time it saves me is beyond belief.

If you aren't using the ORM, what does the admin bring to the table? I agree with the value of the admin, and is one of the reasons in my latest project I kept the Django ORM, even though some coworkers felt it was limiting (it is, but it isn't all about a single component of the system).

Re: Lessons learned defying Joel Spolsky with Django

#39

Post by PommeDeTerre »

drdaeman wrote: post #27
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

This sounds like a situation where it'd just be better to use separate, yet similar, queries, with each handling a particular case or set of conditions.

Views, stored procedures and functions can be used to help isolate duplication, parameterize the queries, or otherwise hide the SQL.

Code like you've posted is the result of taking DRY too far, to the point where avoiding a small amount of repetition ends up bringing in far more complexity and problems than the repetition might cause.

Re: Lessons learned defying Joel Spolsky with Django

#40

Post by zzzeek »

PommeDeTerre wrote: post #21
zzzeek wrote: post #18

Earlier quoted context omitted.

The word "stupid" here is ambiguous, so can be interpreted as, "stupid", "it's stupid to use them" (I disagree), or "stupid", "they don't necessarily understand your intent" (this applies to all software), "stupid", "simple issues are made more complicated than they should be, to an unreasonable extent" (this is a problem that varies to a significant degree based on the ORM in use and cannot be generalized based on t…

You know, you could've just directly mentioned SQLAlchemy earlier...

I don't like making my posts look like plugs for my own stuff, though I guess it's unavoidable....
Post reply on HN