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

81–90 of 209 posts

Re: Django 3.1

#81

Post by moksly »

kumarvvr wrote: post #13

OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?

I work in a C# shop that has added Python to our development, because it runs a long side the poweshell scripts our operations guys build in the managed azure services.

I think Django is just a good package. It’s really productive and the ORM is better and easier to use than entity. The real winner for me is it’s stability though. In the time we’ve gone from classic ASP to web-forms to MVC to modern MVC to .net Core and now soon the new .Net version. Django has remained relatively stable and relatively easy to upgrade.

And make no mistake, we absolutely still operate web-forms applications that will likely never get rewritten in something else.

At the end of the day, tech stacks aren’t really that important though.

Re: Django 3.1

#82

Post by brylie »

heliodor wrote: post #73
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…

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

Some useful ORM extensions that I know of include:

- Core Forms and Class-based views

- https://django-extensions.readthedocs.io/en/latest/model_ext...

- https://django-model-utils.readthedocs.io/en/latest/

- https://django-queryable-properties.readthedocs.io/en/stable...

- https://django-mptt.readthedocs.io/en/latest/

- https://rsinger86.github.io/django-lifecycle/

Re: Django 3.1

#83

Post by acdha »

jpgvm wrote: post #64
snypox wrote: post #44

Earlier quoted context omitted.

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.

Try rewriting your comment like an engineering discussion than an opinion piece: share that experience with specific details about things which worked better or worse, using enough detail for anyone else to be able to decide whether your environment is enough like their own to be applicable.

Since this is a Django thread, that could be covering things about, say, why you prefer .Net forms or trade offs from various ORMs.

I think C# is a quite respectable language so you could cover, say, why its typing is more productive than something like mypy or how package management compares.

Re: Django 3.1

#84

Post by [deleted] »

fastball wrote: post #14
nojs wrote: post #10

Earlier quoted context omitted.

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

I use the JSONP column type in Postgres for data that is structured but user-supplied.

[deleted]

Re: Django 3.1

#85

Post by laactech »

Jonnax wrote: post #3

Cool, they've implemented async views. ASGI has kinda passed me by. For some small project's I use Gunicorn. What's the setup for ASGI that's popular?

I've been running uvicorn with gunicorn in production, and it's been solid. Django 3.0 enabled this with ASGI support. It'll still be a while before django is fully async capable, but these are steps in the right direction.

Re: Django 3.1

#87

Post by nicoburns »

tarkin2 wrote: post #51
kumarvvr wrote: post #13

OT Question : When choosing a stack for creating sites, would you choose Django over ASP.NET Core or PHP? If so, why?

PHP on its own was more of a templating system plus arbitrary code when I used it. Django and ASP.NET have ORMs and templating systems. Lots of people love ORMs although I’ve found complex queries slow with a hefty object model system, to the point where I’d rather write parameterised sql queries than work with a ORM optimization strategy. The templating system is nice although these days I mostly use javascript talk…

PHP has Laravel which is very competitive with Django (and Rails), and IMO quite a bit ahead of ASP.NET in terms of what it provides (although ASP.NET is far ahead of both in terms of performance).

Re: Django 3.1

#88

Post by fabian2k »

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.

In Postgres, NULL values take one bit of storage as far as I understand. So a table has to be very, very wide before this becomes a benefit. Of course if you have attributes that you don't control but are e.g. user-specified, JSONB column are a good choice.

Re: Django 3.1

#89

Post by stefano »

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.

That depends on what that request is doing. It could be fetching a single record from the database and serializing it, or it could be running a complex analysis.

Re: Django 3.1

#90

Post by Alex3917 »

metafunctor wrote: post #66
Alex3917 wrote: post #53

Earlier quoted context omitted.

> 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.

I’ve used it more for generating forms, e.g. for when there are different types of questions or modules can ask or show the user —- multiple choice, free response, upload an image, watch a video, etc. So I’ve used JSON here both for storing the questions and responses, and then have used validators for each question type and response type. The downside is that it’s hard to do migrations. But in most cases you can just save the rendered HTML each user is shown and that covers you for having an audit trail, rather than maintaining backwards compatibility indefinitely. And if you do need to maintain compatibility forever, the schema validators enable that.

Having done or seen almost the exact same use for JSON at multiple startups, for whatever downsides there are I think it’s 10x better than needing to try to understand a bunch of models, each with their own queries and logic.

Post reply on HN