5 ms·
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 pass
by matsemann 2mo ago
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 out of control. Sure, it's nice to reuse MyModel.objects.annotate_something().annotate_something_else().... but it can quickly become unwieldy and even wrong with exploding joins. And it promotes doing queries in places they shouldn't happen.
* It's veeery easy to make spaghetti. Very easy to query across boundaries, into other apps. Fine on smaller projects, but in huge codebases it quickly makes things hard to control, especially since it's all stringly typed. If I want to modify my model, it's hard to know if someone else have done a query where they did theirmodel__some_relation__another_relation__mymodel__some_field. Blows up in production.
* For some reason it's very common in Django/python projects to have types.py, models.py, selectors.py, views.py, services.py etc. And then each of those end up with lots of unrelated things in the same python file, while related stuff is spread over many files. Django apps doesn't really solve this cleanly either.
- DarkNova6 2mo agoI 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 statically typed), but coming from writing apps and backends in Java, Swift, C#, Objective-C and PHP, Python with Django was the worst experience bar none. I worked on the project for 10 months, could at least refactor the project to something semi-sane where obvious mistakes (which would not be possible in other languages) could not happen. Then along comes a "good Python dev" and threw it all out of the window and start doing SQL queries all over the place (typically 3-6 lines long), remove the domain objects and cause the same problems I started with to begin with. But his approach was saying that the other developers were "not good enough". Yeah, have fun with schema changes going forward. Good riddance.
- senko 2mo agoYes, if you attempt to use Django like you'd use your typical Java, Swift, C#, or Objective-C framework, you're not going to have a good time. I've seen the horrors Java devs start doing on a Python project when trying to "fix" things, where by "fix" they mean use patterns they had to in previous gigs. It's a different world.
- DarkNova6 2mo agoHaving basic defensive programming, some simple classes instead of dicts everywhere and avoiding n+1 is a "different world"?
- senko 2mo agoJust 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 a more "consenting adults" than "defensive programming" attitude (which doesn't mean exessive coupling or spaghetti, but the approach is different from the Java or C# mindset). There's no one THE correct style of programming.
- matsemann 2mo ago> 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.
- JodieBenitez 2mo ago> BEGS you to cause n+1 problems select_related, prefetch_related. n+1 problems be gone.
- 2mo ago
- Oxodao 2mo agoI 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.
- JodieBenitez 2mo agoHaving used Doctrine, hard disagree. Never again.
- Oxodao 2mo agoI've used django-orm at my previous job for 2 years and I never have liked it, the syntax is just not nice to read. I used Doctrine for 5 years (2 before last job and 3 since I got my current one) and it's just night and day. Declaring entity is just way cleaner, you can just skim through an EntityRepository / query and understand easily what it does
- zelphirkalt 2mo agoI find those double underscore kwargs weird too, and would prefer to simply pass a lambda instead. What is your idea, what would you suggest?
- ErroneousBosh 2mo agoThe double underscore kwargs are a bit odd, I agree, but once you know about them they're okay. And, rather like the petrol engine, it turns out while it sucks, everything else is massively worse in some vitally important way.
- Oxodao 2mo agoIn Doctrine the query builder can take objects that describe what you want to do [1], not the best but still way better to read and understand. There's also the DQL which is an SQL-like language that's pretty well integrated in phpstorm and is quite close to SQL [2] [1] https://www.doctrine-project.org/projects/doctrine-collections/en/3.1/expression-builder.html https://www.doctrine-project.org/projects/doctrine-collectio... (for collections but you can use them for queries too) [2] https://www.doctrine-project.org/projects/doctrine-orm/en/3.6/reference/query-builder.html https://www.doctrine-project.org/projects/doctrine-orm/en/3.... / https://www.doctrine-project.org/projects/doctrine-orm/en/3.6/reference/dql-doctrine-query-language.html https://www.doctrine-project.org/projects/doctrine-orm/en/3....
- kitsune_ 2mo agoThe 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.
- braiamp 2mo agoWhat would you have done Instagram from instead of Django?
- nesarkvechnep 2mo agoElixir and Phoenix.
- physicsguy 2mo agoYou'd have written Instagram which was released in 2010 in Elixir which wasn't released to the public til 2012?
- pmontra 2mo agoSo Rails or some PHP framework. It was slightly too early to go full Node. Django was a little unusual too among the developers I knew. Java was still a thing but more for finance related projects.
- FranOntanaya 2mo agoWell 2010 PHP and the frameworks at the time were still going through the 5.x desert journey, and the prospects weren't entirely clear with the cancellation of PHP 6, so you wouldn't fault your 2010 self for not trying to push some Drupal/Joomla/Magento to that scale. Kinda took until Facebook showing off Hacklang in 2014 for people to believe in getting more canonical programming features into PHP and make it more performant. So it would have been a good decision if one could predict 10 years into the future, but nobody can.
- adsharma 2mo agoIf you must use Django, use it through an abstraction layer like this: https://adsharma.github.io/django-fquery/ https://adsharma.github.io/django-fquery/ Your models can be plain old python data classes, declaratively mapped to Django primitives.