The only part I don't really agree with, is the avoidance of app separation and signals. It's one of the cleanest ways to decouple your modules and keep some level of sanity in a medium-sized codebase. It comes down to deciding what parts really need to depend on others and be very explicit about that. I generally end up with a few core apps with the main data objects that a lot of other "parallel" ones depend on, a…
What I love about Django
61–70 of 120 posts
Re: What I love about Django
#62Earlier 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.
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…
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)) \
+sin(radians(latpoint))*sin(radians(lat)))) \
as distance from sites_site join \
(select %s as latpoint, %s as lngpoint) as p on 1=1 \
order by distance limit 5", [float(lat), float(lon)])
... which calculates the Haversine distance from where you are now to the five nearest points.I am in roughly equal parts proud of and horrified by this creation.
Re: What I love about Django
#63Re: What I love about Django
#64I feel sufficiently old after having read South in this article. Good god what a throwback. Django is hands down one of my favorite frameworks ever created, and the only one I still reach for in some contexts. For a lot of projects I use it to drive database migrations, and stand up an easy admin portal for others to use - then anything else is driven by an API layer written in (e.g) Rust. I haven't had to care about…
How do your API calls get into the Django app(s)? Do you define the API as well on the Django side (duplicating the API)? Or is there some tool that translates the Rust API calls for Django efficiently?
Re: What I love about Django
#65I really like django, but since being involved in it from early days, whenever someone now praises Django, I am reminded of this talk: https://www.youtube.com/watch?v=i6Fr65PFqfk DjangoCon 2008 Keynote: Cal Henderson
Re: What I love about Django
#66I 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…
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…
Re: What I love about Django
#67I feel sufficiently old after having read South in this article. Good god what a throwback. Django is hands down one of my favorite frameworks ever created, and the only one I still reach for in some contexts. For a lot of projects I use it to drive database migrations, and stand up an easy admin portal for others to use - then anything else is driven by an API layer written in (e.g) Rust. I haven't had to care about…
How do your API calls get into the Django app(s)? Do you define the API as well on the Django side (duplicating the API)? Or is there some tool that translates the Rust API calls for Django efficiently?
Just read from the database and treat Django as a DB builder/migrator/inspector.
Re: What I love about Django
#68I remember, when I used it for the very first time in commercial project. Client briefed me in the afternoon, the next day, before the noon, she got ugly app, but with fully working admin backend. She was sold. But I also remember, that some non-standard requirements were really difficult to implement or get around. Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add…
> Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support. How long ago was this? I feel like unicode has kind of been a solved problem in Python since python3 came out. In the python2 days it was, indeed, miserable.
Re: What I love about Django
#69Earlier quoted context omitted.
I despise django-orm, doctrine is so much better. Like, who thought that using named arguments to do stuff was a proper way ??? `.filter(created_at__gte=XXXXX)` why? The rest of the framework is great but the ORM is definetly its weakest point.
I find those double underscore kwargs weird too, and would prefer to simply pass a lambda instead. What is your idea, what would you suggest?
And, rather like the petrol engine, it turns out while it sucks, everything else is massively worse in some vitally important way.
Re: What I love about Django
#70I'd love Django, if they had a better async story ... I used it for a recent project. While the framework is overall amazing, I had to switch to Go for better performance and easier async support.