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

71–80 of 209 posts

Re: Django 3.1

#71

Post by kerkeslager »

konschubert wrote: post #4

Slightly OT: How does HN feel about the recent craze to make web python asynchronous? To me, the performance gains are dubious in many cases and the complexity overhead of handling cooperative multitasking just seems like a step back for a language like python.

99% of Django apps are CRUD apps with zero need for this. It's easy to get sucked into new-hammer-ism where you have a new hammer and start seeing nails where there aren't any.

The 1% where this is needed does exist, but I suspect that there are far more people using the new async features than actually have need for them. And if you don't need them, you're introducing a lot of complexity, without mature tooling around it to reduce that complexity.

Probably 5 years from now there will be mature tooling around this stuff that lowers the complexity so that it is a good tradeoff for average websites. But for now, I don't need to be an early adopter.

Re: Django 3.1

#72

Post by dempseye »

bzb3 wrote: post #67
danpalmer wrote: post #42

Earlier quoted context omitted.

90% of the time I don't want it. Database, cache, etc, not really that bothered. Web requests take 100-300ms to complete, tying up a worker for 300ms isn't much of a problem. 10% of the time I'm calling an API that takes 3s and tying up a worker for 3s _might_ be a problem. Being able to not do that would be really handy sometimes. Not web servers, but I also do a lot of web scraping and Python is definitely the best…

Web requests taking over 100 ms is an absolute shame that slow languages like python are enabling.

Most of the times I've profiled a web application I found that slow requests were coming from slow database queries.

Re: Django 3.1

#73

Post by heliodor »

metafunctor wrote: post #27
grenoire wrote: post #6

JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.

In projects I've been involved with, storing JSON in the database has often turned out to be a mistake. Django models create a well-defined self-documenting structure for your schema, are easy to evolve using migrations, and there's a wealth of tooling built on top. IMHO, these far outweigh the perceived convenience of simply storing some stuff in a JSON field. If you find yourself implementing your own validation an…

Can you please elaborate on the "wealth of tooling" part? Makes me wonder what I don't know...

Re: Django 3.1

#74

Post by arusahni »

waihtis wrote: post #68
StavrosK wrote: post #59

Earlier quoted context omitted.

Yeah, I think you were thinking some sort of auto-refresh.

That was exactly what I was hoping this to be.

Perhaps django-reactor would be of interest to you? [1] It's targeting LiveView-like functionality for Django. I haven't used it (so I can't vouch for the claim).

1: https://pypi.org/project/django-reactor/

Re: Django 3.1

#75

Post by whouweling »

leowoo91 wrote: post #30
whouweling wrote: post #9

Earlier quoted context omitted.

Well, if you have external API calls in your Django app and you are running sync (which I would absolutely advice, with running async it is really easy to get an unpredictable performance which is sometimes hard to track down) having the ability to run some views async is really crucial. Otherwise your application might me humming along smoothly at some point and coming to a sudden complete standstill or performance…

Isn't that why gunicorn(+gevent) was implemented and does the switching behind the scenes w/o waiting that api call to finish? Is there a good reason I should manually "await" network calls from now on?

Yes; gevent does also fix this problem. But it also gives you a lot of new problems when running all requests async. In my experience mostly with views that (in some specific calls, i.e for a specific customer) keep the cpu tied up, for example serializing a lot of data. Random other requests will be stuck waiting and seem slow while it is a lot more difficult to find out which view is the actual problem.

I have deployed applications both under gevent and sync workers in gunicorn and would personally never use gevent again, especially in bigger projects. It makes the behavior of the application unpredictable.

Re: Django 3.1

#76

Post by zmmmmm »

nojs wrote: post #10
grenoire wrote: post #6

JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.

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.

Re: Django 3.1

#77

Post by wil421 »

formerly_proven wrote: post #35
StavrosK wrote: post #33

Earlier quoted context omitted.

100% agreed, JSON fields are good when you want to dump a bunch of data you don't care about the shape of, but if you need a schema, pull the data into actual fields.

For a database like postgres, or even for something like SQLite, this mostly becomes a distinction without a whole lot of difference, since the database can index and access JSON structures just like regular columns.

What’s a real world example where you would choose to index the JSON as you said rather than putting them into the fields/schema.

Re: Django 3.1

#78

Post by leetrout »

I hope they prioritize some support for ROLLUP and friends.

I’d never used it before and it was fantastic but I had to drop down to raw sql to do it. SQLAlchemy has had support for well beyond a year.

I’ve used Django since 2008 and I love it with all its warts but I’ve really grown to prefer SQLAlchemy.

Re: Django 3.1

#80

Post by fleetfox »

nojs wrote: post #10
grenoire wrote: post #6

JSONField has been an absolute godsend in combination with Django's ORM. I had been using it with Postgres and will likely keep our backend the same, but I cannot recommend it enough. You will have to write some validation and schema code on top if you want your data to have similar (but weaker) guarantees to the usual typed fields; the benefits from the flexibility you get are immeasurable though.

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

There are scenarios when you can't avoid EAV and then JSON is great even when it's for denormalized data.
Post reply on HN