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

Django 5.0

djangoproject.com

Post reply on HN
Print view View original

91–100 of 237 posts

Re: Django 5.0

#91

Post by h4kor »

freedomben wrote: post #5
h4kor wrote: post #3

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility mor…

Have you worked with ActiveRecord or Ecto? Just wondering for framing your comment

I briefly used Ecto when trying out Phoenix framework but have not worked enough with it to form an opinion.

Re: Django 5.0

#92

Post by fbdab103 »

DarkNova6 wrote: post #11
h4kor wrote: post #3

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility mor…

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORMs because some minority of generated queries are problematic.

If maximum performance, 100% of the time was the end-goal, I would not be writing Python.

Re: Django 5.0

#93

Post by radus »

cdcarter wrote: post #82
jmduke wrote: post #22

My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance. Not a lot of whizbang features in 5.0, but Gen…

GeneratedField looks interesting, but I'm not _really_ sure what gains I get over just calling annotate() on my queryset with some computed fields. At least on the backends where the computed GeneratedField isn't stored.

It's easier to re-use if you need the same generated field in multiple places.

Re: Django 5.0

#94

Post by h4kor »

DarkNova6 wrote: post #11
h4kor wrote: post #3

Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility mor…

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

I'd rather have a slow page because of lazy loading, than a wrong page because the related objects are not loaded (i.e. typeorm)

Re: Django 5.0

#95

Post by fbdab103 »

har777 wrote: post #48
DarkNova6 wrote: post #11

Earlier quoted context omitted.

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

Simple middleware can warn you about lazy loading/N+1 queries. Most of the time people just forget it happens. Try using: https://github.com/har777/pellet Disclaimer: I built it :p You can easily see N+1 queries on the console itself or write a callback function to track such issues on your monitoring stack of choice on production.

Have a pitch on what differentiates this from django-toolbar? Just the focus on query count monitoring?

Re: Django 5.0

#96

Post by zelphirkalt »

sprainedankles wrote: post #26
jmduke wrote: post #22

My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance. Not a lot of whizbang features in 5.0, but Gen…

Any resources/examples you'd recommend for a Vue frontend w/django? I've been pretty firmly in backend land for a while and would to experiment with the other half of the puzzle!

If you really need VueJs in the frontend, consider, that you can simple serve the VueJs on any page where it is actually needed. VueJs does not necessarily mean you must create a SPA. VueJs can be delivered like any other script and this is often the easiest way without having to commit to build a full blown SPA.

Re: Django 5.0

#97

Post by tomwojcik »

ds3w2 wrote: post #40

django is good just one thing fix .select_related('child__attribute') / .values('child__attribute') currently it removes from result set rows where 'attribute' is NULL, unlike what typical LEFT JOINs imply

I never run into this issue but isn't it that Django uses inner join for select related, so it does what it's supposed to do?

You can always prefetch related, or even use outer=True. This will return the results you expect.

Re: Django 5.0

#98

Post by h4kor »

belorn wrote: post #27
DarkNova6 wrote: post #11

Earlier quoted context omitted.

> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong. Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries. But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic…

Yes you do have to work on your queries to keep them fast with growing complexity. Django also has a usable intermediate API to construct your queries, instead of writing raw SQL. Nice feature to have if you don't want to commit to a specific database yet.

And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.

Re: Django 5.0

#99

Post by ajhai »

I've been using Django as my main choice for web projects for over ten years. The reason I like it so much is because it comes with a lot of built-in features that one needs to ship web projects to production. For example, I was first attracted to Django because of its admin interface and its straightforward views and templating system.

Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins.

My recent use of Django is in (https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.

Post reply on HN