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

61–70 of 209 posts

Re: Django 3.1

#61

Post by maxmalysh »

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.

There is no _switch_! You can use easily _mix_ sync and async code without any consequences.

Django provides `sync_to_async` and `async_to_sync`, but it's trivial to do this yourself without Django:

https://docs.djangoproject.com/en/3.0/topics/async/#async-ad...

You can write sync code and use async calls only when needed.

Also, async python is awesome. Things were messy 2-3 years ago, but everything is so much better now.

Re: Django 3.1

#63

Post by nix23 »

jpgvm wrote: post #60
nix23 wrote: post #46

Earlier quoted context omitted.

>C# is a better language by far and the .NET runtime is a better runtime by far. Big nono!!

I don't see how this is controversial... C# is a powerful language that is highly expressive, has a great type system, excellent compiler and great IDE, excellent async support, fast HTTP stack in standard library, blessed application development framework and object relational mapper, etc. Basically everything you could ask for in an ecosystem for developing a long-lived web application. Python is a scripting langua…

>Tbh I don't think there is much contest.

Maybe but you should always ask for what, that's the main-point. Sometimes Java or even Javascript/Node is the best stack. Many many point's play into a decision for a web-stack, maybe he wants that "quickly", maybe he works in a C# shop and so on....

Re: Django 3.1

#64

Post by jpgvm »

snypox wrote: post #44
jpgvm wrote: post #29

Earlier quoted context omitted.

Then ASP.NET is probably the superior choice. C# is a better language by far and the .NET runtime is a better runtime by far. It only ever makes sense to use Python for data-science one-offs and munging if you have competency in Java/C#/etc. It's not a language well suited to application development.

Don’t understand why you got downvoted. I work in a Python shop and 100% agree with you.

Yeah I think my mistake is posting a response to a question about which language to use in a Python thread and not suggesting Python.

I work with Python every day and have for years and it's strengths and weaknesses are readily apparent to me but not to everyone apparently.

Re: Django 3.1

#65

Post by kerkeslager »

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.

How long have you been using this?

My intuition says this is one of those tradeoffs that is fast and easy in the short run, but over time becomes technical debt. I haven't used these over the long term, though.

Re: Django 3.1

#66

Post by metafunctor »

Alex3917 wrote: post #53
metafunctor wrote: post #27

Earlier quoted context omitted.

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…

> If you find yourself implementing your own validation and schema code for JSON fields, I'd say it's a sign that you should probably stop and migrate the data to Django models instead. Don't agree. Where JSON fields with validators are useful is when you would otherwise have inherited models for different variants of the same type of thing. It's a lot easier to understand and query one model with 50 Cerberus (or wha…

Like I said, there are some cases where using JSON fields makes sense. Good examples would be cases where you wish to retain the structure of the data, but don't have control over it. Sounds like you're describing a case like that.

Re: Django 3.1

#67

Post by bzb3 »

danpalmer wrote: post #42
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.

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.

Re: Django 3.1

#68

Post by waihtis »

StavrosK wrote: post #59
waihtis wrote: post #56

Earlier quoted context omitted.

After taking a uninterrupted reading slot to understand the async views, you're right, and I had the concept understood wrong.

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

That was exactly what I was hoping this to be.

Re: Django 3.1

#69

Post by rsinger87 »

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?

Storing arbitrarily complex Boolean queries (think Elasticsearch's query syntqx). While this could be done in SQL tables, there are no gains with referential intregity and while there would be some in consistency, I don't think they're worth it.

Re: Django 3.1

#70

Post by dempseye »

orf wrote: post #15
nojs wrote: post #10

Earlier quoted context omitted.

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

Storing historical webhook notifications

The bonus with this is that at the start you are probably only interested in a few of the fields in the webhook, but as your application develops, you may need to extract more. If you've stored the JSON of previous webhooks, you have an easy migration path.
Post reply on HN