Hacker News Reader

Comment by acjohnson55 | Hacker News Reader

I could nail those with the Django ORM, but I'd struggle to write syntactically correct SQL, not having done it in a while. But it says that your test machine has MS-SQL; with the machine in front of me, I could probably puzzle it out the join quirks with a couple minutes of trial and error.

View on HN

I think if you don't give someone a machine you should be pretty forgiving about exact syntax.

Someone who can put together a statement that's broadly right with small errors normally means someone who is rusty (or nervous) but knows their stuff rather than someone who is guessing and a couple of follow up questions will usually confirm that.

General rule for me: don't ask anything that a decent IDE or 10 seconds with a manual / help file / Google would have prevented (unless you've given them a decent ID or similar in which case it's fair game).

So the question is, do you represent yourself as a SQL developer? If not, no drama.

How would you solve the first one using Django ORM?

    Employee.objects.filter(boss__salary__lte=F('salary')).values_list('names', flat=True)

Employee.objects.filter(boss__salary__lte=F('salary'))

Find me employee objects which have a boss salary less than or equal to the salary.

Out of curiosity, would the ORM map to the same SQL query? Or would it request all employee-boss pairs and filter them outside of the DB?

There's a huge performance difference involved.

I believe Django would do this as a single query.

this is a good question. my experience with the django ORM is that in general it resolves any call to an ORM method into SQL and nothing else, but it is not guaranteed to generate the most optimal SQL.

It is however, a somewhat common practice of django devs to to do some post-processing on a queryset in Python. totally acceptable for small querysets with complicated logic, but, yeah, obviously unacceptable for large performance critical queries.

Potentially huge performance difference.

For the 99% use case, the performance hit fo the ORM is not significant enough to matter. Most projects have many tables, but only one table that actually needs to have any speed optimizations. That one table can go in NoSQL and the rest can be handled by a ORM.

It will only be one query. The django orm won't do any filtering outside the DB that is up to you.

It does not apply to the first question, but how does the ORM handle joined columns from other tables? Is it embedded somewhere in the returned object? The best way I could think to handle this using an ORM would be for the object to contain a set of arbitrary key/value pairs to contain joined columns but it seems like a hack.

It is fetched dynamically e.g. employee.boss.department. That will usually cause two more queries to the database. You can use select_related and prefetch_related so that these objects will be loaded into the ORM in one or two queries.

  from .models import Employee
  from django.db.models import F

  print Employee.objects.filter(
      salary__gt=F('boss__salary')
  )

Reply on news.ycombinator.com