Cayla  Erdman

Cayla Erdman

1596897060

Speed up your Django Admin By Removing SQL Counts — Optimizing Django: Part 2

The Django admin portal can clunky and slow in some places, but in this short article, I’m going to try to help make it more efficient for you, at a small price.


So, what’s wrong with it?

Well, the Django admin is a great tool for getting out a solid Django back-office user interface with minimal additional developer effort. Adding an admin interface for a Django model is literally a couple of lines of code away, and for a developer trying to balance making features work against making features accessible to non-technical people (like their clients), this is a great help.

However to make the Django admin easy to drop in comes at some costs, one of them being speed. Take the page counter.

Image for post

1 user in the DB (red box)

With just one user, the SQL queries look like this:

Image for post

Quite good, actually.

Notice the SELECT COUNT values in the request. For 1 user, that’s no problem. In fact, it’s okay even with 10k users:

Image for post

However, trying the same with 500k users causes the SQL times to begin to add up.

Image for post

Image for post

I’d demo with more users but I don’t want to bust my local DB for a screenshot

Anyone who deals with Django beyond small-scale may be familiar with this problem, especially when dealing with through models. For example, a social media backend might use through tables for recording subscriptions or comments (the big players tend to use Redis or some other cache implementation to serve those much more quickly, but for more permanent records a DB like Postgresql is the gold standard). You can imagine how quickly those tables would explode and make their admins unusable.

You can also opt to not use the admin, but what a waste that would be. So let’s see if we can fix it by removing the count queries.

#postgresql #sql #django #django-rest-framework

What is GEEK

Buddha Community

Speed up your Django Admin By Removing SQL Counts — Optimizing Django: Part 2
Cayla  Erdman

Cayla Erdman

1594369800

Introduction to Structured Query Language SQL pdf

SQL stands for Structured Query Language. SQL is a scripting language expected to store, control, and inquiry information put away in social databases. The main manifestation of SQL showed up in 1974, when a gathering in IBM built up the principal model of a social database. The primary business social database was discharged by Relational Software later turning out to be Oracle.

Models for SQL exist. In any case, the SQL that can be utilized on every last one of the major RDBMS today is in various flavors. This is because of two reasons:

1. The SQL order standard is genuinely intricate, and it isn’t handy to actualize the whole standard.

2. Every database seller needs an approach to separate its item from others.

Right now, contrasts are noted where fitting.

#programming books #beginning sql pdf #commands sql #download free sql full book pdf #introduction to sql pdf #introduction to sql ppt #introduction to sql #practical sql pdf #sql commands pdf with examples free download #sql commands #sql free bool download #sql guide #sql language #sql pdf #sql ppt #sql programming language #sql tutorial for beginners #sql tutorial pdf #sql #structured query language pdf #structured query language ppt #structured query language

Ahebwe  Oscar

Ahebwe Oscar

1620177818

Django admin full Customization step by step

Welcome to my blog , hey everyone in this article you learn how to customize the Django app and view in the article you will know how to register  and unregister  models from the admin view how to add filtering how to add a custom input field, and a button that triggers an action on all objects and even how to change the look of your app and page using the Django suit package let’s get started.

Database

Custom Titles of Django Admin

Exclude in Django Admin

Fields in Django Admin

#django #create super user django #customize django admin dashboard #django admin #django admin custom field display #django admin customization #django admin full customization #django admin interface #django admin register all models #django customization

Cayla  Erdman

Cayla Erdman

1596897060

Speed up your Django Admin By Removing SQL Counts — Optimizing Django: Part 2

The Django admin portal can clunky and slow in some places, but in this short article, I’m going to try to help make it more efficient for you, at a small price.


So, what’s wrong with it?

Well, the Django admin is a great tool for getting out a solid Django back-office user interface with minimal additional developer effort. Adding an admin interface for a Django model is literally a couple of lines of code away, and for a developer trying to balance making features work against making features accessible to non-technical people (like their clients), this is a great help.

However to make the Django admin easy to drop in comes at some costs, one of them being speed. Take the page counter.

Image for post

1 user in the DB (red box)

With just one user, the SQL queries look like this:

Image for post

Quite good, actually.

Notice the SELECT COUNT values in the request. For 1 user, that’s no problem. In fact, it’s okay even with 10k users:

Image for post

However, trying the same with 500k users causes the SQL times to begin to add up.

Image for post

Image for post

I’d demo with more users but I don’t want to bust my local DB for a screenshot

Anyone who deals with Django beyond small-scale may be familiar with this problem, especially when dealing with through models. For example, a social media backend might use through tables for recording subscriptions or comments (the big players tend to use Redis or some other cache implementation to serve those much more quickly, but for more permanent records a DB like Postgresql is the gold standard). You can imagine how quickly those tables would explode and make their admins unusable.

You can also opt to not use the admin, but what a waste that would be. So let’s see if we can fix it by removing the count queries.

#postgresql #sql #django #django-rest-framework

Ahebwe  Oscar

Ahebwe Oscar

1624206000

Django bugfix releases issued: 3.2.3, 3.1.11, and 2.2.23 | Weblog | Django

Today we’ve issued 3.2.33.1.11, and 2.2.23 bugfix releases.

The release package and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for this release is Mariusz Felisiak: 2EF56372BA48CD1B.

#django #weblog #django bugfix releases issued #3.2.3, 3.1.11, and 2.2.23 #django bugfix releases issued: 3.2.3, 3.1.11, and 2.2.23 | weblog | django

Ahebwe  Oscar

Ahebwe Oscar

1624194540

Django security releases issued: 3.2.4, 3.1.12, and 2.2.24 | Weblog | Django

Django security releases issued: 3.2.4, 3.1.12, and 2.2.24

Posted by Carlton Gibson  on Tháng 6 2, 2021

In accordance with our security release policy, the Django team is issuing Django 3.2.4Django 3.1.12, and Django 2.2.24. These release addresses the security issue detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2021-33203: Potential directory traversal via admindocs

Staff members could use the admindocs TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by the developers to also expose the file contents, then not only the existence but also the file contents would have been exposed.

As a mitigation, path sanitation is now applied and only files within the template root directories can be loaded.

This issue has low severity, according to the Django security policy.

Thanks to Rasmus Lerchedahl Petersen and Rasmus Wriedt Larsen from the CodeQL Python team for the report.

CVE-2021-33571: Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros in IPv4 addresses

URLValidatorvalidate_ipv4_address(), and validate_ipv46_address() didn’t prohibit leading zeros in octal literals. If you used such values you could suffer from indeterminate SSRF, RFI, and LFI attacks.

validate_ipv4_address() and validate_ipv46_address() validators were not affected on Python 3.9.5+.

This issue has medium severity, according to the Django security policy.

Affected supported versions

  • Django main branch
  • Django 3.2
  • Django 3.1
  • Django 2.2

#django #weblog #django security releases issued: 3.2.4, 3.1.12, and 2.2.24 #3.2.4 #3.1.12 #2.2.24