Live data from Hacker News

What I love about Django

buttondown.com

111–120 of 120 posts

Re: What I love about Django

#111

I really like the ORM and the migrations, but some parts I really dislike. They're maybe not Django's fault, but how it's used most places: * Models being passed around everywhere, queries happening everywhere. I prefer having a dedicated service/selector layer to do those things. Then convert to pydantic objects or something that's passed around further. * Corollary, but adding stuff to querymanagers quickly goes ou…

If you must use Django, use it through an abstraction layer like this:

https://adsharma.github.io/django-fquery/

Your models can be plain old python data classes, declaratively mapped to Django primitives.

Re: What I love about Django

#112
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)…

Site.objects.annotate( distance=Degrees(ACos(Cos(.....))), latpoint=float(lat), lngpoint=float(lon), ).order_by("distance")[:5]

for function calls, look at django.db.models.functions, you can find a bunch of stuff in there or create custom ones super easily (like "two lines of codes" easily)

I mean you have a thing that works in theory so it's a bit of navel gazing, though.

Re: What I love about Django

#113

Earlier quoted context omitted.

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

See sibling comment about fetch modes in coming 6.1 (https://docs.djangoproject.com/en/dev/topics/db/fetch-modes/), you can have a FieldFetchBlocked.

Re: What I love about Django

#114
post #56

Earlier quoted context omitted.

Having basic defensive programming, some simple classes instead of dicts everywhere and avoiding n+1 is a "different world"?

Just asking these questions underscores lack of understanding how things are usually done in Django and Python in general. In Django you'd typically use simple classes (models or forms, or even dataclasses nowadays) more than dicts everywhere; n+1 is trivially avoidable (as another sibling comment points out, and you also have multiple packages that autodetect such cases if you've missed them). Python in general has…

> Just asking these questions underscores lack of understanding how things are usually done in Django and Python in general.

No, it doesn't. It's fair to criticize the consequences of this approach to coding.

Re: What I love about Django

#115
post #60

Earlier quoted context omitted.

The ORM is really not good in my opinion because it is ActiveRecord'ish and has all its downsides. I wouldn't use Django for any moderately complex domain. But even with simpler CRUD style apps I don't really see the point in it.

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…

The other thing that I think people tend to forget is that there are plenty of situations where N+1 queries just aren't that big a deal. Not every view in every application that every developer builds needs to handle massive amounts of traffic with low latency and high cardinality tables. I've built so many apps where there's one or two users, small amounts of data, etc. And even on apps that do have a lot of traffic, there are often internal/admin/maintenance views that don't have the same requirements and no one will notice an N+1 where N = 5 in the worst possible case.

Every time ORMs get discussed, it seems to be dominated by people who are like "but my app has 5 billion concurrent users doing 2 million requests per second and if there's an extra 5ms on my requests, it will all explode!" and can't comprehend that not everyone is building the same kind of systems all the time. Great, maybe an ORM isn't appropriate for your situation.

Re: What I love about Django

#116
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…

The other thing that I think people tend to forget is that there are plenty of situations where N+1 queries just aren't that big a deal. Not every view in every application that every developer builds needs to handle massive amounts of traffic with low latency and high cardinality tables. I've built so many apps where there's one or two users, small amounts of data, etc. And even on apps that do have a lot of traffic…

[dead]

Re: What I love about Django

#117

Earlier quoted context omitted.

It's made by DHH.

Some people are just looking to be offended. You don’t have to read or agree with his drivel to use his software. (Do you also check out the blogs/social media of every dev involved in every library you use?)

> You don’t have to read or agree with his drivel to use his software.

No, but a lot of people choose to, and I don't claim to know if one way or the other is more right or righteous. But I think boycotts wouldn't exist in the first place if everyone could separate the art from the artist.

And since there's lots of boycotts in the world, I think it's safe to say that it's at least socially acceptable to boycott companies or people with practices you don't like.

Who are we to say they're wrong for it?

Re: What I love about Django

#118
post #112

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)…

Site.objects.annotate( distance=Degrees(ACos(Cos(.....))), latpoint=float(lat), lngpoint=float(lon), ).order_by("distance")[:5] for function calls, look at django.db.models.functions, you can find a bunch of stuff in there or create custom ones super easily (like "two lines of codes" easily) I mean you have a thing that works in theory so it's a bit of navel gazing, though.

That is actually awesome :-) I'll try that.

I was really just going to try and wrap it in a function to stick in the model so I can say something like Site.objects.get(id=thing).distance_from(lat,long) in.

But, now the bit that I was calling that from is actually being done from a websocket handler, and that's written in Go because Django and websockets seems very complex.

Re: What I love about Django

#119
post #53

Earlier quoted context omitted.

I need to go look up the CEO of my refrigerator, dishwasher, couch, car, cell phone, TV, shirt and jeans, and oat milk to see if they said anything I disagree with on social media so I can boycott them.

I mean, that might not be the worst thing? Like, if you have something you regularly spend a lot of money on, it might be worth spending 2min on the Wikipedia article about it’s manufacturer to verify that it’s not made by child slaves or someone who sends all their profits to the KKK or whatever. Doing that seems like basic prudence for an interconnected world, and a far cry from like … digging around Reddit threads…

Update: I read DHH’s blog. I now have an opinion on DHH: not good.

Re: What I love about Django

#120

Earlier quoted context omitted.

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?

It looks like GeoJSON implements some distance lookups that make this more django-y, that's probably the easiest way. But I doubt they're using raw() either.
Post reply on HN