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

101–110 of 144 posts

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

#101

Post by rowanseymour »

yurishimo wrote: post #55
rowanseymour wrote: post #34

Earlier quoted context omitted.

If it were up to me there'd be a way to completely disable it globally for all models. Let me explicitly enable it when I'm just shelling around or checking results in unit tests. It is not a feature for production environments.

Laravel does this (or at least has a config for it). You can disable lazy loading in non-production environments which will throw fatal errors whenever a model is lazy loaded. The nice part is, in prod, that code _allows_ lazy loading since application stability is more important. Hopefully at that point you have a good performance monitoring tool that will alert you to that problem. Laravel also has hooks to more gr…

Hmm I would call lazy loading the opposite of a sharp knife that requires skill.. you're not being explicit about database work. You're relying on the framework to bail you out where you've forgotten a fetch. And by default Django will do that silently so missing prefetches easily go undiscovered.

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

#102

Post by helpfulContrib »

bruce343434 wrote: post #48
santiagobasulto wrote: post #41

I think Django's ORM is just AMAZING. And as with every other tool, it has to be used wisely. First, it let's you get started quickly and prototype. You can write unit tests, make sure everything is working as expected, then count queries and make sure you're being efficient with your SQL engine. Second, and even more importantly, it's crucial in the definition of the app and the Schema. Thinking in high level "class…

We've had serious trouble with migration merges when two people work on different parts of the code, yet in the same module, and they both generate a "migration nr. 6" on their feature branches.

[dead]

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

#103

Post by rowanseymour »

stavros wrote: post #73
wruza wrote: post #32

Earlier quoted context omitted.

What would be the best way?

There's a Django app (that I forget the name of) that disables lazy loading in templates, thus requiring you to load everything explicitly in the view.

I think there's a few 3rd party solutions like https://github.com/charettes/django-seal but I don't love the idea of using something that I assume is monkey patching Django code.

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

#104

Post by helpfulContrib »

ruthmarx wrote: post #45
nprateem wrote: post #24

This is largely academic now. LLMs do a good job of writing highly complex queries with the django ORM. All you need is the django toolbar so you can check their efficiency, then keep telling it to make them more efficient.

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

[dead]

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

#105

Post by CraigJPerry »

jampekka wrote: post #65
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…

> 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? One big why is SQL. It's a horrible language/API but sadly practically all relational databases are SQL.

This is the nail on the head.

I’m really not a fan of ORMs, I don’t think they save any time because to use them in a safe way, you NEED to fully understand the SQL that will be run. There’s no shortcut from this and it’s plainly just an extra step.

I’ve been bitten too many times but one ironic problem is that they’re so damned reliable. 99.999% of the time your use of an ORM will be just fine. It can be hard to argue against sometimes even though that 0.001 time can be an extinction level event for the company.

So if you need to understand the SQL that will be run anyway and ORMs occasionally introduce disastrous behaviour, why persist with them?

Well to start with the obvious, SQL is not panacea, you can still be bitten with non-deterministic behaviour when you hand craft every query in sql (e.g. when was the last time you updated stats on that relation - will the optimizer select an appropriate strategy?).

But a stronger reason is that some harder queries just suck to write correctly in SQL. Maybe you’re working with some kind of tree or graph and need a recursive common table expression: Enjoy! It might be better in most cases to write such a query at a higher level of abstraction (ORM) and take advantage of the more productive testing facilities.

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

#106

Post by reportgunner »

DarkNova6 wrote: post #74
andybak wrote: post #51

Earlier quoted context omitted.

Not at my desk but from memory, this is a something with a clearly documented "solution". I put that word in quotes because I don't want to imply it's a problem - it's just something you need to know how to handle.

That's the problem I have with Python mentality. Everything is great, you just need to know about the myriad of pitfalls and problems. A good environment makes problems obvious and and allows to communicate decisions clearly. This is the trap of the local maximum.

> ..with Python mentality

As opposed to what mentality ? I mean any tool I worked with has the same problem.

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

#107

Post by listenallyall »

9dev wrote: post #81

I’ve used several ORMs and experienced the same things everyone else does—CRUD is great, but good luck with your first actual reporting dashboard. Then I tried the new generation of typescript SQL query builders that automatically infer types from your database and provide end-to-end type-safe query results, even for highly complex queries. And since then I became convinced the answer isn’t trying to shoehorn classes…

You'd probably really like jooQ, building queries with typed classes and returning strongly-typed results. Of course, it runs on the JVM where languages have actual types, not a facade over an untyped language.

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

#108

Post by sgarland »

nprateem wrote: post #96
sgarland wrote: post #89

Earlier quoted context omitted.

And the title of Software Engineer becomes even more meaningless. Imagine an electrical engineer saying, “I don’t really know what a bridge rectifier is, but I plugged these things into the breadboard where ChatGPT told me, and the output signal looks correct.”

The engineering is in saying "I need to get this data within these performance constraints", not in the now worthless knowledge of exactly how to fetch it.

That’s not engineering, it’s operating. There’s nothing wrong with operators as a career field, but don’t equate it to engineering, and don’t expect to be as highly paid (why should you be? You can’t fix it when it breaks, and you don’t know how it works).

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

#109

Post by sgarland »

jampekka wrote: post #88
sgarland wrote: post #86

Earlier quoted context omitted.

So horrible that it’s been the standard for 50+ years. The relational model is great. Embrace it, because it isn’t going anywhere.

Relational model is good, SQL is not. They are not the same thing.

Short of academic languages like D, nothing faithfully implements the relational model. Some compromises are necessary to make it useful for practical applications, hence SQL.

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

#110

Post by eru »

jampekka wrote: post #65
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…

> 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? One big why is SQL. It's a horrible language/API but sadly practically all relational databases are SQL.

I agree that SQL ain't great.

You can model relations in your language without using SQL. (You could have a mapper from your internal modelling of joins etc to how you talk to your database.)

In eg Haskell that works really well, but other languages are also flexible enough.

Post reply on HN