Django 3.1 • Hacker News Board

Re: Django 3.1

#121

Post by jsmeaton » Tue, Aug 04, 2020, 2:19 PM UTC

true_religion wrote: post #112

leetrout wrote: post #96

Earlier quoted context omitted.

Yea I started to bring up the existing ticket for grouping on the dev list and ask what people thought about it. I also ended up writing a very tiny transformer function and using that directly because core only has a couple supported casts and I needed Postgres timestamp types so I could extract and rollup on the year / month / day. That gave me some insight in to some of the patterns in use in “lower level” Django…

SQLAlchemy has a great architecture, but it comes at the expense of being tied to the use case of accessing a relational database. Django models are more abstract and anemic in querying, but it means you can use the same API and write access layers for non SQL databases. At work, we have an in memory database, and Elastic Search all queried in an identical way to the Postgres models.

I’d be super keen to see your ElasticSearch model implementation if you’re allowed to share it?

For what it’s worth, I dislike the unit of work model that SQLA uses, but the layered architecture is enviable.

Re: Django 3.1

#122

Post by simonw » Tue, Aug 04, 2020, 2:22 PM UTC

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 using Uvicorn for a couple of years on a whole bunch of projects and it's not caused me any trouble at all.

Re: Django 3.1

#123

Post by pyrophane » Tue, Aug 04, 2020, 2:22 PM UTC

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?

The Django Admin is Django's "killer app." If a significant portion of your application is a back-office CRUD admin interface, Django is perhaps the most productive way to build something like that without writing a bunch of forms or using something even more out-of-the-box {like a Drupal). If you become proficient with Django you can build custom CRUD admins very quickly.

For other use cases, there are better frameworks out there.

Re: Django 3.1

#124

Post by true_religion » Tue, Aug 04, 2020, 2:24 PM UTC

nicoburns wrote: post #91

turing_complete wrote: post #50

Earlier quoted context omitted.

I work mostly in Python and I like it. However, C# is a great, and for some reason underrated, language that is certainly better along a number of dimension.

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.

Re: Django 3.1

#125

Post by VWWHFSfQ » Tue, Aug 04, 2020, 2:25 PM UTC

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?

Gunicorn with the Uvicorn worker class is the recommended production solution

Re: Django 3.1

#126

Post by anentropic » Tue, Aug 04, 2020, 2:25 PM UTC

whouweling wrote: post #75

leowoo91 wrote: post #30

Earlier quoted context omitted.

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 depl…

How does async/await solve this? I would have thought it has exactly the same problem?

Re: Django 3.1

#127

Post by anentropic » Tue, Aug 04, 2020, 2:27 PM UTC

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?

Python

Re: Django 3.1

#128

Post by selectnull » Tue, Aug 04, 2020, 2:30 PM UTC

collyw wrote: post #115

stefano wrote: post #92

Earlier quoted context omitted.

By default yes, but you can configure queries fetching behavior using select_related/prefetch_related to avoid the N+1 queries problem.

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 are of course tools that can help with that (django-debugger and others).

Re: Django 3.1

#129

Post by rs999gti » Tue, Aug 04, 2020, 2:35 PM UTC

kumarvvr wrote: post #116

rs999gti wrote: post #114

Earlier quoted context omitted.

Does the backend language of a CMS matter? We are a .NET shop, we'd love to use Django, Drupal, etc. But does that also mean we need a dedicated Python resource to support these CMS'? Or could we use these CMS' out of the box? Or would we just be better off with a .NET CMS like Umbraco or Orchid?

Once you have an app deployed, it takes a life of its own. Absolutely, the whole stack matters a lot.

So the backend language of the CMS does matter, because we'll eventually have to modify it to fit business needs?

Re: Django 3.1

#130

Post by mrweasel » Tue, Aug 04, 2020, 2:42 PM UTC

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?

Product data on a webshop. If you have a wide selection of product categories you’ll have a huge number of attributes that aren’t relevant across your categories.

There’s a number of ways to deal with the issue, e.g. a model per category or an EAV database pattern (this is what platforms like Magento does). None are really ideal, but storing the product attributes as JSON works pretty well. Even more so when your database supports querying the JSON blob.