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

Django 3.1

djangoproject.com

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Django 3.1

#151

Post by yebyen »

selectnull wrote: post #128
collyw wrote: post #115

Earlier quoted context omitted.

Sadly not so many people know how to use those. From the Django projects that I have inherited at least.

Django ORM mainly hides the SQL from the developer (which is kind of the idea of any ORM). But if a developer does not understand the underlying SQL concepts, they will soon write performance wise horrific code. But, if you remove the ORM from that equation, I don't see how that same developer doesn't make the same mistakes. So in the end, I don't think that Django ORM (in its core) can help much in this area. There…

This is a hot-take from Aaron Patterson, Rails and Ruby core team dev, in his keynote this year where he addressed a very similar idea on a perhaps related query generation topic...

https://youtu.be/9JEEabL90AA?t=1360

To give you the tl;dr (he goes through profiling and a great deal of data to help show what a core dev needs to do in order to help us solve this one specific case, and...)

Aaron comes to the conclusion that there is a "performance pro-tip" which many Rails devs have learned, similar to what y'all are discussing in this thread for Django, and in this one specific case he outlines in some detail, Aaron considers that there is a bug where the programmer needs to know this "pro-tip."

As there was really no reasonable way for the Rails engine to interpret this instruction from the programmer as to mean "do it the slow way" when there's a better way to do the same thing with no drawbacks, and it would have been possible for the engine to safely do the smarter thing (it was IIRC to precompile some better-shaped SQL, bringing back the same result set in fewer queries, (making up the most runtime performance by spending less time in the SQL compiler overall, in the worst performing pathological case, all this is shown with data)...) and that having this behavior here is actually much better for a novice programmer's behalf, in order to make that better performance happen without requiring a developer to manually build such hints into the application code, at abstraction layers where they really shouldn't have to be thinking about those things anyway.

Re: Django 3.1

#152

Post by woadwarrior01 »

zmmmmm wrote: post #76
nojs wrote: post #10

Earlier quoted context omitted.

Can you give some examples where a relational schema isn’t suitable?

Sparse data. For example, if there are 1000 possible attributes, only 5% are populated for any given row. If you have 1000 columns you are going to have a ridiculously wide and mostly empty table.

The traditional approach to efficiently modelling data like that with relational databases is to use the EAV[1] model, which works quite well in practice.

[1]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...

Re: Django 3.1

#153

Post by Alex3917 »

d33 wrote: post #8

Pardon the rant, but I feel that the advantages don't outweigh the fact that with each release some of my stuff gets broken and I need to adjust. Django puts DeprecationWarnings basically everywhere and it's a hell to maintain projects that had been alive for a few years. God forbid you do anything with the interfaces they expose. The problem is only getting worse when you consider your dependencies, which in many ca…

For me, upgrading Django for a series-A sized startup (e.g. 25KLOC) takes maybe 2 - 4 hours on average, assuming there is good integration test coverage. What parts of the upgrade process are you finding take a long time?

I feel like the last Django release that was at all complicated to upgrade to was maybe 1.9, in terms of getting the test cases to run properly in parallel if they hadn't been properly isolated. And even that was more of a Python3-like situation, where it really only exposed things that people had done incorrectly previously.

Re: Django 3.1

#154

Post by WD-42 »

whouweling wrote: post #28
viraptor wrote: post #24

Earlier quoted context omitted.

> plummets when a random external API endpoint starts to time out You should add something like https://pypi.org/project/circuitbreaker/ Continuously failing external requests should not make each one of your responses slow.

Interesting, will certainly try it out, thanks! > Continuously failing external requests should not make each one of your responses slow. It is not really a matter of the responses becoming slow, the problem is that if you are running sync with i.e 6 application server processes and you have just 6 hits on an endpoint in your app that is hung up on an external API call your application stops processing requests altog…

Exactly this. I see the whole django async stuff being far more relevant for applications with lots of traffic or high request rates where you are already running on beefy infrastructure with a ton of workers and any small improvement in performance translates into huge real world cost savings. Your standard blog, no so much.

Re: Django 3.1

#155

Post by doteka »

no_wizard wrote: post #148
sammorrowdrums wrote: post #144

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a…

Looks like they will be relying on the ASGI pattern for this? Has anyone had any practice deploying apps with ASGI?

Last time I tried deploying Django (with Channels) on ASGI around 2017 or 2018, it was a total clusterfuck and fell over with about 20 websocket connections, and we had to scramble to revert that deployment. That’s not ASGI’s fault though, as there are several reasonably performant frameworks using it.

Re: Django 3.1

#156

Post by WD-42 »

d33 wrote: post #8

Pardon the rant, but I feel that the advantages don't outweigh the fact that with each release some of my stuff gets broken and I need to adjust. Django puts DeprecationWarnings basically everywhere and it's a hell to maintain projects that had been alive for a few years. God forbid you do anything with the interfaces they expose. The problem is only getting worse when you consider your dependencies, which in many ca…

I'm sorry, but this is just programming. You have two choices: 1. Never upgrade and keep everything stable but go through hell when you inevitably must update something or 2: keep up with the latest and go through some minor pain with every release.

It's a lot like taking care of a house or car.

The world does not stand still, much less programming frameworks.

Re: Django 3.1

#157

Post by jungletime »

As someone that has an active app still written in Django 1.6. The larger my project and more complicate the more I wanted to ditch the model/view/template separation. And attach methods to the model so that it can be called from everywhere, returning html code in a string directly.

Other times, I wished Django had something analogous to a component, where everything is just encapsulated in a single file. I don't want to separate javascript/html/css view/template. I want a single file I need to update and an easy way to call to render.

The template system is also difficult to use, if you get complicated scenarios.

I needed to show event details in a modal if that was the user preference. But the page could also be embedded. This lead to me having to render differently depending on the device, whether it was embedded and if it was a popup or not. This lead to an explosion of possibilities, a total 2x2x2 = 8 different views for the same data in the same template.

The most practical way was with if / then statements but that still lead to me repeating html code. And being difficult to reason about and test.

I also got into situation where the template wasn't parsed and updated. Probably because of too many includes or inheritance in the template. For example, I wanted to write a custom css file that would use google fonts that the user selected in the UI. The only way I found to work was to bypass the template and write a function in the view that would render_to_string the css file.

Re: Django 3.1

#158

Post by icey »

true_religion wrote: post #124
nicoburns wrote: post #91

Earlier quoted context omitted.

I didn't downvote, but IMO it's only half true: C# and the runtime really are excellent. But the C# library ecosystem is much smaller than the Java, JavaScript, PHP, and Python ecosystems (and even Go/Rust for a lot of things), and there are even quite a few commercial (paid for) libraries! This may not matter for a particular project, but for me it's significant enough to not make C# a universal recommendation. Hope…

Also, historically C# ran terribly on Linux, or had a bunch of gotchas when it came to interfacing with the rest of the MS ecosystem. I don’t know if that is still true today.

It’s no longer true (at least the performance bits), especially with the upcoming release of .NET 5.

Re: Django 3.1

#160

Post by sammorrowdrums »

no_wizard wrote: post #148
sammorrowdrums wrote: post #144

I'm surprised the discussion has derailed into whether or not to use JSON fields... Certainly you don't have to, but they've been in Postgres contrib for a long time. Async views have dropped, and that is genuinely exciting. It's taken a lot of work, and there's still a ways to go before Django is truly async native, but this is one of the big steps, and being able to do some concurrent IO on a few routes could be a…

Looks like they will be relying on the ASGI pattern for this? Has anyone had any practice deploying apps with ASGI?

Have a production Django site running with Gunicorn / Uvicorn worker and we haven't hit any snags yet. Mind you we're only beginning to use it for anything in particular. The test was to check performance was acceptable, and stable - which has been our experience so far.
Post reply on HN