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

Taming the beast that is the Django ORM – An introduction

davidhang.com

Post reply on HN
Print view View original

121–130 of 144 posts

Re: Taming the beast that is the Django ORM – An introduction

#121

Post by winrid »

roze_sha wrote: post #16
wg0 wrote: post #13

Earlier quoted context omitted.

Nope. Python type hinting is far far from Java like types. And yes, I guess OP has now a large system that needs types enforced by the system to reduce the friction in evolving the stack.

What about using pydantic?

I already use type annotations with Python for use within my IDE. It's just all tiring garbage. Java is already almost a scripting language and I can actually use a shared heap, etc. also I have some core code in java I use in the desktop app I want to reuse in the server. Right now I transpile that core code to TS and then JS to use client side, but I'd rather just have everything in Java.

Re: Taming the beast that is the Django ORM – An introduction

#122

Post by AmericanChopper »

nprateem wrote: post #85
AmericanChopper wrote: post #47

Earlier quoted context omitted.

I personally don’t think DB migrations are that difficult, and I’d say they can be done a lot safer without an ORM. I’ve also never found an ORM that was easier to learn and overall easier to use than SQL. I’ve never understood how ORMs became so popular, I don’t get how somebody can look at how opaque and complicated they are and conclude that learning an ORM is easier than just learning SQL.

Because it's not about avoiding SQL (although that's a benefit), it's that you also get forms for free, view classes, easy APIs, validation, a free admin, free docs and a large pool of potential employees who all understand the foundations of your app.

You don’t get any of that for free. You get it at the cost of working with the abstractions, which can be very high. Your RDBMS is not an OOP/multi-paradigm system like Python is (or whatever other language). Its objects interact differently, and it has different access patterns. Any system you use to try and ignore these differences is just going to create a host of other problems for you, especially this idea that it will allow you to simply ignore database administration.

Re: Taming the beast that is the Django ORM – An introduction

#123

Post by Izkata »

djeiejejejej wrote: post #22
wsc981 wrote: post #8

Earlier quoted context omitted.

I've started working on a .NET project that uses EntityFramework and due to some of the magic, I prefer just using raw SQL as well. I've used other ORM solutions in the past as well and I am not a fan ... But the team chose EF due to it supposedly being easier to integrate with whatever database the customer might be using and that seems like valid reasoning.

Yes I agree. That’s a valid argument, but there are other ways as well like SQLKata and other query builders. Depending on the complexity of the product I think writing standard SQL92 will get you far as well. I don’t get how an ORM will handle Postgres’ CTEs and windowing functions. Those are pretty basic and extremely useful features to me, but those require dropping to raw SQL. Each vendor has those useful particu…

> I don’t get how an ORM will handle Postgres’ CTEs and windowing functions. Those are pretty basic and extremely useful features to me, but those require dropping to raw SQL. Each vendor has those useful particularities that you immediately lose by going ORM.

Django has supported windowing functions since 2.0, almost 7 years ago: https://docs.djangoproject.com/en/2.0/ref/models/expressions...

And people are experimenting with CTEs - this looks pretty natural to use, at least with the basic example, and it supports recursive CTEs even if the example looks clunky (though I think that's their choice of example rather than the actual recursive part making it look bad): https://dimagi.github.io/django-cte/ (repo: https://github.com/dimagi/django-cte)

Re: Taming the beast that is the Django ORM – An introduction

#124

Post by ebcode »

raziel2p wrote: post #90
ebcode wrote: post #40

Anytime I hear ORM, I always think of this: https://blog.codinghorror.com/object-relational-mapping-is-t...

I tried reading and understanding the arguments made here, but just could not make any correlation with my day to day experience using ORMs. is it possible that the fact this article is written in 2006 simply makes it dated? it seems very catastrophizing but we've come a long way and are just more aware of how to work with or around the shortcomings and flaws of ORMs. I've often written programs where I'm trying to e…

I probably should have linked to the original article[1] instead of codinghorror's summary.

I don't think the article being from 2006 (or 2004) makes it dated (though it does have a date). I think it addresses a fundamental issue with ORMs that will always be there, which makes it a bit of a classic.

David Hang's Django ORM article has a bullet-point section on ORM cons, including "difficult debugging", "performance", "hides underlying SQL". Whereas Neward's article goes into depth on each of the following topics:

The Object-Relational Impedence Mismatch

The Object-to-Table Mapping Problem

The Schema-Ownership Conflict

The Dual-Schema Problem

Entity Identity Issues

The Data Retrieval Mechansim Concern

The Partial-Object Problem and the Load-Time Paradox

If you haven't read the original article, I highly recommend it. You'll learn a bit more about "Vietnam" (from a US perspective), and be better equipped to discuss and make decisions about ORMs afterward.

[My own opinion is that ORMs can be useful (I wouldn't say never use one), but that a programmer should be grounded in SQL and the relational model[2] first, so that they'll know when to, and when not to, use one.]

[1] https://web.archive.org/web/20220823105749/http://blogs.tedn...

[2] https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

Re: Taming the beast that is the Django ORM – An introduction

#125

Post by ninetyninenine »

sgarland wrote: post #87
ninetyninenine wrote: post #50

orms are exercises in OCD. Databases are the bottleneck your classic website. We choose to query these databases in a extremely high level language called SQL. This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. A better abstraction would be one that's a bit more similar to a standard programming language with an std…

> This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. What? You have to understand a language to write performant code in it. That’s not a hack, that’s basic competence.

No it's not. Many language are designed so certain performance aspects are invisible. Take golang and python: The garbage collector.

The garbage collector is something you should not think about when programming and most programmers don't even need to know it exists. You only think about it when you need to seriously optimize things.

For SQL it's a bad design choice because of what SQL is and what SQL is targeting.

SQL is a high level abstraction that automatically determines a query plan based off of high level input. The problem here is that it can choose a bad query plan. So you need to "hack" the query in order to trick the query planner into doing what you want.

It's also targeting the slowest part of the stack: Non volatile memory and IO. The slowest part of the stack should be targeted with a zero cost abstractions to maintain speed while the fastest part of the stack you can use a language like python for your web app it's fine because databases are magnitudes slower.

Re: Taming the beast that is the Django ORM – An introduction

#126

Post by bal00ns »

eru wrote: post #63
exceptione wrote: post #58

Earlier quoted context omitted.

There is one part in me that says to not destroy your positive mood, there is another part in me that wishes to yell at the pythonistas in general to look outside the Python world. Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python. I see that as a general…

ORMs are a bad idea in the first place: relations are a great way to organise your data, why would you want to sully that by converting to something object oriented? > Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python. To give a nice counterexample: Python…

They’re incredibly convenient. It allows smaller groups of people to accomplish more in a shorter amount of time by providing a standardized interface that does a great job of integrating with their existing environment. When translating database input and output into server-side representations, you have two options: build and maintain the process yourself or use a mature tool designed for that specific purpose in your server-side language. I strongly prefer the latter, as do many others. I find that most people critical of ORMs end up creating their own narrowly focused, weakly tested ORM-like database compatibility layers in their backend. These have caused more problems than ORMs ever have.

Re: Taming the beast that is the Django ORM – An introduction

#127

Post by jampekka »

DarkNova6 wrote: post #115
jampekka wrote: post #80

Earlier quoted context omitted.

https://spring.io/guides/gs/spring-boot

This is not even a counter argument. We are talking ORMs here, not dependency injection frameworks. The Java equivalent to Django ORM would be Hibernate. It doesn't strike me that you know what Spring does, nor where its own features end.

The comment I replied to was to general development. And Spring is the most popular Java web framework (that it's called a "dependency injection framework" is kinda telling about the architectural ideology).

I've had the misfortune to use both Spring and Hibernate professionally.

Re: Taming the beast that is the Django ORM – An introduction

#128

Post by sgarland »

ninetyninenine wrote: post #125
sgarland wrote: post #87

Earlier quoted context omitted.

> This language is so high level that you need to come up with tricks and query analyzers in order to hack the high level query into something performant. What? You have to understand a language to write performant code in it. That’s not a hack, that’s basic competence.

No it's not. Many language are designed so certain performance aspects are invisible. Take golang and python: The garbage collector. The garbage collector is something you should not think about when programming and most programmers don't even need to know it exists. You only think about it when you need to seriously optimize things. For SQL it's a bad design choice because of what SQL is and what SQL is targeting. S…

Point taken re: gc.

For query plans, in nearly every plan flip I’ve encountered, the root cause came down to either poor table / column statistics (because they had let the table grown too large without appropriate tuning), having an enormous amount of joins beyond the deterministic level the planner could provide, or sub-optimal queries. The latter is growing less common as planners get better and better at rewriting on the fly, but it’s always good to know how to do things optimally.

A good example is semijoins / antijoins. With modern versions of both MySQL and Postgres, you’ll probably have “WHERE foo IN (…)” turned into “WHERE EXISTS (SELECT 1…)”, but it’s better to write it the optimal way in the first place.

I will grant you that indexing can be bewildering, with its many rules, caveats, and gotchas.

Re: Taming the beast that is the Django ORM – An introduction

#129

Post by ruthmarx »

nprateem wrote: post #83
ruthmarx wrote: post #45

Earlier quoted context omitted.

LLMs are not at a point where we should be treating them as a solution to any software engineering issue, period.

I've used it to write horrendously complex queries across multiple tables. It can do things I don't know how to and that would have taken significant time to learn. All I know is it works and it's performant when you tell it to be. It's been particularly helpful for aggregations, subqueries etc. You may not think LLMs are there yet but my project is proof. Try it yourself.

> It can do things I don't know how to and that would have taken significant time to learn. All I know is it works

Until it fucks up and you have no clue how to fix it, and either does the LLM.

Re: Taming the beast that is the Django ORM – An introduction

#130

Post by eru »

bal00ns wrote: post #126
eru wrote: post #63

Earlier quoted context omitted.

ORMs are a bad idea in the first place: relations are a great way to organise your data, why would you want to sully that by converting to something object oriented? > Too often I come across Python projects that are hyped and when I dive into it I find it rather underwhelming to say it politely. Invariably it turns out that those people don´t know any other language than Python. To give a nice counterexample: Python…

They’re incredibly convenient. It allows smaller groups of people to accomplish more in a shorter amount of time by providing a standardized interface that does a great job of integrating with their existing environment. When translating database input and output into server-side representations, you have two options: build and maintain the process yourself or use a mature tool designed for that specific purpose in y…

> When translating database input and output into server-side representations, [...]

I'm saying that your server side representation could also be done as a relation. No need for object orientation. I don't have a problem with the M part of ORM, but with the O part.

_If_ you are having different representations, than having an automated mapper between representations is good. Agreed, yes.

Post reply on HN