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

What I love about Django

buttondown.com

Post reply on HN
Print view View original

101–110 of 120 posts

Re: What I love about Django

#101

Post by ranger_danger »

ErroneousBosh wrote: post #62
rtpg wrote: post #59

Earlier quoted context omitted.

The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want. It can take a while to wrap your head around what fields get used in aggregates and the like, but when working with big models with like 65 fields and juggling a bunch of stuff, not having to futz with serialization/deserialization and "just" expressing your problem in the dumb way…

> The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want. And if you can't make the ORM make the SQL query you want, you can just write it as a SQL query, like this godawful monstrosity: x = Site.objects.raw("select id, name, lat, lon, 111.045*degrees(acos(cos( \ radians(latpoint))*cos(radians(lat)) \ *cos(radians(lngpoint)-radians(lon)…

I'm not seeing anything that can't be done here without using raw() though?

Re: What I love about Django

#102

Post by ranger_danger »

JodieBenitez wrote: post #35
DarkNova6 wrote: post #26

Earlier quoted context omitted.

I seriously don't get why Django ORM is using the Active Record pattern. This is such a stupid footgun that trivially causes horrible performance and BEGS you to cause n+1 problems. Never in my life did I have a problem with lazy loading causing unbearable performance until I joined a Python Django team. I really tried to find sympathy for the "dynamically typed" folks (please spare me saying Python is technically st…

> BEGS you to cause n+1 problems select_related, prefetch_related. n+1 problems be gone.

It still selects all fields by default. Very often I have to use defer() or only() to get rid of expensive columns like blob/text that are rarely used and greatly hurt performance when grabbing them.

Then it got to where I had to make a reflective function that I use like Model.objects.defer(*all_fields_except(Model, ['field1', 'field2'])), and then add another all_fields_except() for every select_related and prefetch_related.

Even save() by default re-writes every single field. You have to use save(update_fields=['field1']) instead.

Re: What I love about Django

#104

Post by sgt »

strogonoff wrote: post #88
sgt wrote: post #60

Earlier quoted context omitted.

I mean if you're doing it this way, you're really not applying best practices as a developer (never mind as a Django developer). > Models being passed around everywhere, queries happening everywhere. No, as a developer you still need to be 100% aware of the underlying queries and potential performance issues. No excuse for N+1 problems. ORM is not an excuse to be lazy, but I admit it will probably catch quite a few d…

Django allowing queries to be anywhere is more or less in line with Python’s overarching “we’re all consenting adults here” ethos. There’s probably one correct way to do it, but if you want to shoot yourself in the foot then here’s your gun. It definitely takes a bit of discipline. The key layers are somewhat easy to manage—middleware, context processors, views, template tags—but I’ve seen some hairy lasagne further…

I'm semi-assuming we're talking about professionals who'd excel with their products in any framework and language.

It's highly productive if you do it right.

Re: What I love about Django

#105

Post by daft_pink »

I like Django too, but find it difficult to deploy. While frontend frameworks can be easily deployed via a cdn and some microservice backends on something like cloudflare or aws, I find Django very difficult to deploy because it needs an underlying server running 24/7.

Re: What I love about Django

#106

Post by lozenge »

JodieBenitez wrote: post #75
DarkNova6 wrote: post #41

Earlier quoted context omitted.

You misunderstand. And that is exactly the problem. We did do that and that's why our queries ended up being several lines long. But if you missed just one model? You openly walk a knife again. It's a mess and it only gets longer and longer. I ended the project with having some proper aggregates, only for that to be thrown out of the window by the guy after me.

> our queries ended up being several lines long Which is... perfectly normal for non-trivial needs. > I ended the project with having some proper aggregates, only for that to be thrown out of the window by the guy after me. How is that a Django problem though ? Sounds like a skill issue on your successor. I get what you say, there's plenty of debates about ActiveRecord vs. AnythingElse, but in the end this one has it…

I think there's an argument for throwing AttributeError instead of silently going to N+1 behaviour.

Re: What I love about Django

#107

Post by cudder »

stuaxo wrote: post #9

Nice. I've been meaning to do my own Django post, on some other bits we take for granted - I should do it. People should be using Django, the best parts are so useful you don't notice them until you switch platforms and implement them badly. Every app that used a more narrow solution ultimately ends up implementing parts of Django badly. The best way to solve this from Djangos side would be to have official ways of:…

Shout out to nanodjango, I researched all the single file options I could find some time ago and it had the best ergonomics imo. Not affiliated, just a fan.

https://nanodjango.dev/

Re: What I love about Django

#108

Post by gls2ro »

dzonga wrote: post #80

Django while opinionated is very flexible too. unlike Rails. that means you can mold it to fit your use case easily - don't like the ORM - you can plug SQLalchemy and use a different 'architecture'. + you can use multiple different databases if you think that's the right path. in Django there's no 'the rails way' - you choose your own path. Django-admin by itself saves so much work specially If you're doing B2B stuff…

Rails is flexible too. Everything that you mentioned here can also have the sample flexibility in Rails: You can use Arel and skip AR, you can use Plex instead of HTML and so on.

The Rails Way is a response to people changing too much Rails and making it super custom.

In the last 4 years alone I touched codebases ranging from Rails Way to Rails and everything dry.rb, to Rails and Grape and Sorbet, to Rails and service objects everywhere and a lot more combinations.

Re: What I love about Django

#109

Post by ErroneousBosh »

ranger_danger wrote: post #101
ErroneousBosh wrote: post #62

Earlier quoted context omitted.

> The one thing I really appreciate with the ORM is that you really can get the ORM to make... more or less any sort of SQL query you want. And if you can't make the ORM make the SQL query you want, you can just write it as a SQL query, like this godawful monstrosity: x = Site.objects.raw("select id, name, lat, lon, 111.045*degrees(acos(cos( \ radians(latpoint))*cos(radians(lat)) \ *cos(radians(lngpoint)-radians(lon)…

I'm not seeing anything that can't be done here without using raw() though?

Yeah I'm not clever enough to do that.

How would you have approached it?

Re: What I love about Django

#110

Post by infamia »

DarkNova6 wrote: post #41
JodieBenitez wrote: post #35

Earlier quoted context omitted.

> BEGS you to cause n+1 problems select_related, prefetch_related. n+1 problems be gone.

You misunderstand. And that is exactly the problem. We did do that and that's why our queries ended up being several lines long. But if you missed just one model? You openly walk a knife again. It's a mess and it only gets longer and longer. I ended the project with having some proper aggregates, only for that to be thrown out of the window by the guy after me.

If you want to just prefetch everything throughout a project or just on a per-Queryset basis, all that is coming in the next release of Django.

https://docs.djangoproject.com/en/dev/releases/6.1/#model-fi...

That's the great thing about Django, it's been around so long and the quality bar is so high that eventually all the major rough edges get sanded away usually in a really well considered manner.

Post reply on HN