Live data from Hacker News

Lessons learned defying Joel Spolsky with Django

speakerdeck.com

21–30 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#21
post #18

Earlier quoted context omitted.

You're contradicting yourself. Your first comment indicates that it's wrong to label ORMs as "stupid". Yet in this latest comment, you've labeled all software (which includes ORMs, of course) as "stupid". Like the other commenter requested, can you provide an example of an ORM that isn't "stupid"? Your initial comment makes it sound like you've worked with at least one that isn't. We're curious to learn about which t…

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...

Re: Lessons learned defying Joel Spolsky with Django

#22
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.

Do you have an example of an ORM which is not in some fundamental way "stupid"? I haven't found one yet, but I'd love to know one existed somewhere.

You should take a look at the ORMs that are considered a bit more at the top of their class. In the Python world SQL Alchemy in the Ruby world Sequel. While you can't judge all ORMs by looking at a few these do offer a better impression of what an ORM can do for you.

Re: Lessons learned defying Joel Spolsky with Django

#23
post #14

Did someone understand the last slides about the differences between transactions in tasks with and without celery ? I'm using celery, and i have been using django in the past, and I really didn't get the point.

He's trying to avoid the situation where you enqueue a background job inside a transaction and the worker gets started on that job before the transaction is committed. If the job needs to hit the database for any reason your likely to get errors as the new data hasn't been committed yet.

It looks like the work around he used is to cache the job queue locally and only flush it to the real job queue after the database commit, so your guaranteed whatever data may be needed for the job has been committed to the database.

Re: Lessons learned defying Joel Spolsky with Django

#24
post #14

Did someone understand the last slides about the differences between transactions in tasks with and without celery ? I'm using celery, and i have been using django in the past, and I really didn't get the point.

Basically if you modify data in a transaction, add a task to the queue that relies on that data, and the worker pulls the task off the queue BEFORE the transaction is committed, then the task tries to access data that doesn't exist in the database yet.

Re: Lessons learned defying Joel Spolsky with Django

#25
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?

There are still a lot of Django apps that work fine in this scenario. Plus I don't think the slides imply that they are just blindly replacing ORM calls with raw SQL, just that they have profiled and replaced the hot spots.

Also Flask is a micro-framework and Django is a full-stack framework. Flask can be used as the backbone of a full-stack framework but figuring out a good project structure and finding out what third-party apps to use can be daunting for a person without Flask experience. If you really want to get people to switch, package up a Flask-based framework with the features of Django.

Re: Lessons learned defying Joel Spolsky with Django

#26
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?

Middlewares, context processors, forms, (class based) views, and tons of third party applications.

The CTO of a startup where some friends are working thought the same you did, and 2 years ago rewrote everything to Flask. Now they're going back to Django.

Django is much more that an ORM and templates.

Re: Lessons learned defying Joel Spolsky with Django

#27
post #15
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?

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 technically possible, but I haven't seen any library that does it.

Re: Lessons learned defying Joel Spolsky with Django

#28
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.

Re: Lessons learned defying Joel Spolsky with Django

#29
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 is asked to do.

In the latter case, the query is simply verifying that object_id is NULL, which is exactly what it's asked to do.

Re: Lessons learned defying Joel Spolsky with Django

#30
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?

"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?

Post reply on HN