Live data from Hacker News

Taming the beast that is the Django ORM – An introduction

davidhang.com

71–80 of 144 posts

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

#71

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…

For pythonistas reading this: JVM and .NET frameworks are better for large projects in the sense that they turn even the simplest projects into large messes of pointless byzantine buggy architecture, which in some circles is a sign of "high quality". Edit: That said, learning multiple programming languages (paradigms) is a very good idea. A reasonable dose of e.g. Java, .NET or C++ for example is great for understand…

> For pythonistas reading this: JVM and .NET frameworks are better for large projects in the sense that they turn even the simplest projects into large messes of pointless byzantine buggy architecture, which in some circles is a sign of "high quality".

You got to back up this claim. The technologies you mentioned are entirely orthogonal to the architecture you are using.

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

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

Something in the official docs or more like shared through blogs or stackoverflow ?

It's in the standard docs:

https://docs.djangoproject.com/en/5.1/topics/migrations/#ver...

You just rename one of the two files, and add the dependency. If they touch the same fields, you obviously have to resolve that manually.

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

#73
post #32

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this ( https://code.djangoproject.com/ticket/30874 ). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 q…

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.

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

#74
post #51

Earlier quoted context omitted.

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.

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.

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

#75
I thought Django’s ORM was awesome (seriously).

And yet using it was such a shit experience I switched permanently to writing SQL.

I see zero advantage to using an ORM over SQL and in fact see many downsides.

Don’t use an ORM just learn SQL. It’s faster, more direct, more powerful, easier to understand, allows you to make full use of the power of the database and your knowledge isn’t suddenly valueless when you go to a project with a different ORM.

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

#76

For me the killer feature of django is the auto-generated admin UI. I initially started my last project using Spring boot, but I was astonished to find there was no equivalent. I don't know how people build websites in any speed without such a tool. I guess they just waste time duplicating effort on an admin UI or pay for one of those tools that can generate one from an API (meaning they have to also build an API). I…

I don’t really understand this, I was very much underwhelmed by the admin UI, and feel like I’m missing something? I mean what does it do other than list records and provide some basic forms to CUD those?

It feels like much of the value in that is achieved even better by using a proper database client, say, JetBrains‘ database integration. I certainly wouldn’t let any business people touch a Django admin panel, or at least those I’ve seen built by our data guys. Way too technical.

And don’t even get me started on extensibility. I wanted to have like, an additional page to include a Grafana iframe plus a bunch of buttons. Something that would take me about five lines in Laravel, for example. Good luck even searching the documentation for this…

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

#77

I adore the Django ORM but as listed under cons... it makes it very hard to avoid accidental N+1 queries, and they don't seem interested in addressing this ( https://code.djangoproject.com/ticket/30874 ). Yes lazy loading is neat when you're messing around on the shell, but you should absolutely not be leaning on it in production at any kind of scale. So instead you have to use unit tests to hopefully catch any N+1 q…

It is a huge red flag to me when people recommend Django ORM without admitting the pitfalls of the Active Record pattern. This is a problem which simlpy doesn't need to exist and it's wasting computing and dev resources time and time again.

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

#78

I thought Django’s ORM was awesome (seriously). And yet using it was such a shit experience I switched permanently to writing SQL. I see zero advantage to using an ORM over SQL and in fact see many downsides. Don’t use an ORM just learn SQL. It’s faster, more direct, more powerful, easier to understand, allows you to make full use of the power of the database and your knowledge isn’t suddenly valueless when you go to…

Depends on what you are doing. A good ORM lets you create entities from tables, or creates tables from entities.

Good ORMs make sure your data model is always aligned with the DB, and there is no way in hell a runtime error can occur. What's more, it automates the mindless data class/table matching for 99% of your use-cases.

Once you got a more sophisticated query, please use SQL. But for simple stuff, use ORM.

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

#79

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.

Yet people do, will continue doing so, and it works. Trying to stuff the toothpaste back into the tube isn’t going to work, insisting on people just using plain text mail, or stop calling the pound symbol hashtag. It’s just old men yelling at clouds.

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

#80

Earlier quoted context omitted.

For pythonistas reading this: JVM and .NET frameworks are better for large projects in the sense that they turn even the simplest projects into large messes of pointless byzantine buggy architecture, which in some circles is a sign of "high quality". Edit: That said, learning multiple programming languages (paradigms) is a very good idea. A reasonable dose of e.g. Java, .NET or C++ for example is great for understand…

> For pythonistas reading this: JVM and .NET frameworks are better for large projects in the sense that they turn even the simplest projects into large messes of pointless byzantine buggy architecture, which in some circles is a sign of "high quality". You got to back up this claim. The technologies you mentioned are entirely orthogonal to the architecture you are using.

https://spring.io/guides/gs/spring-boot
Post reply on HN