DEV Community: Rahul Mishra

What is Django ContentType

Rahul Mishra — Mon, 23 Aug 2021 05:31:34 +0000

In this series, we will understand Django's ContentType and what is GenericForeignKey with examples. contenttypes is a Django app that can track all of the models installed in our Django-powered project, providing a high-level, generic interface for working with our models.

If we check in settings INSTALLED_APPS we can see, that django.contrib.contenttypes is readily present.

INSTALLED_APPS = [
    ...
    'django.contrib.contenttypes',
    ...
]

Since contenttypes is just like any other app, it also has migrations and, and views.py. The most important model of the contenttypes app is ContentType. Let's see what fields ContentType has.

class ContentType(models.Model):
    app_label = models.CharField(max_length=100)
    model = models.CharField(_('python model class name'), max_length=100)
    objects = ContentTypeManager()

    class Meta:
        verbose_name = _('content type')
        verbose_name_plural = _('content types')
        db_table = 'django_content_type'
        unique_together = [['app_label', 'model']]

    def __str__(self):
        return self.app_labeled_name

Apart from the custom manager, it has app_label and model both as string fields, which also are unique_together.

app_label is the name of the application the model is part of.
model is the name of the model itself.

We have already established that ContentType is a model that tracks all the models in your Django app and therefore, as soon as we create a new table in the database, a new entry gets created for the new table in the ContentType table. Consequently, ContentType model objects "points" to a particular table in your Django app. Let's see few entries in the ContentType table.

>>> from django.contrib.contenttypes.models import ContentType

>>> ContentType.objects.filter(model='user').values()
<QuerySet [{'id': 4, 'app_label': 'auth', 'model': 'user'}]>

>>> ContentType.objects.filter(model='contenttype').values()
<QuerySet [{'id': 5, 'app_label': 'contenttypes', 'model': 'contenttype'}]>

Since ContentType itself is a model, the ContentType model also tracks itself and thus has an entry for itself, this sounds a bit confusing but makes complete sense.

ContentType model has 2 important methods, model_class and get_object_for_this_type, let's see with an example what these methods do.

>>> from django.contrib.contenttypes.models import ContentType

>>> user_ct = ContentType.objects.get(model='user')
>>> user_ct.model_class()
django.contrib.auth.models.User

>>> user_ct.get_object_for_this_type(username='bob')
<User: bob>

Okay, so now at this point we know what ContentType is, but what good is it for? Why do we need this?

GenericForeignKeys are implemented via ContentType, we will see this in the next part of this article about how ContentTypes are used.
The admin application uses it to log the history of each object added or changed through the admin interface. Django’s authentication framework uses it to tie user permissions to specific models.
Since we have all models listed here in one place, we can use this to build generic solutions.

In this article, we understood about ContentType model and contenttypes framework, in the next article, we will see one of the implementations of ContentType which is GenericForeignKey.

To read more, please visit: https://buildatscale.tech/what-is-django-contenttype/

Transaction Isolation Levels In Innodb

Rahul Mishra — Sun, 11 Jul 2021 15:26:25 +0000

First, let's break the heading, a Transaction is a sequential group of statements, queries, or operations that performs as a single work unit that can be committed or rolled back. Next, Isolation is the I of ACID properties, isolation refers to the ability to concurrently process multiple transactions in a way that one does not affect another. Lastly, Innodb is the default storage-engine for Mysql. In this article, we will understand the different isolation levels available in MySQL-InnoDB.

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.02 sec)

Isolation level can be set for all sessions, i.e. set globally or set per session. The default transaction isolation level is REPEATABLE-READ.

There are 4 levels of transaction isolation available in MySQL.

READ-UNCOMMITTED: As the name suggests, transactions can read data that are not even committed to the database leading to dirty reads.

In the above example, we started 2 sessions, set the isolation level to READ-UNCOMMITTED in both session, and we can see, that in session 1 we can read data which is not committed by session2.

READ-COMMITTED: In this level, dirty-reads are not possible, as only committed data can be read in select, however, each subsequent read can be non-repeatable. Let's see examples to understand.

In the above example, we can see, that only committed writes were selected, which fixes the dirty-read problem, however, each read would result in different results if other transactions are committed, this leads to non-repeatable reads.

REPEATABLE-READ: This is the default transaction isolation level of Innodb. In this isolation level, select yields the same value as a snapshot of the first execution of SELECT is taken and that is used until the transaction ends. With this both dirty-read and non-repeatable reads are handled, however, we may get phantom rows with repeatable-read isolation levels.

In the above example, we started transactions in both the sessions, we can see, that even if the write has been committed to the database, all reads in transaction 1 are still yielding the same result.

In the above example, we see that transaction 1, now has 1 new row which is also a phantom-row.

SERIALIZABLE: This isolation level is the strongest possible isolation level, but this also increases the chances of locking conditions. This is done by use of shared read locks and exclusive write locks. SERIALIZABLE is similar to REPEATABLE READ with the additional restriction that the row selected by one transaction cannot be changed by another until the first transaction finishes. Let's see an example.

In the above example, we can see that when we tried to insert a new row in different transactions, Lock wait timeout exceeded error. This guarantees the fix from phantom-rows.

And there you have it, all 4 transaction isolation levels explained with examples. We have also seen that the isolation level is a balance between consistency and throughput. High consistency (SERIALIZABLE) means more locking conditions/less throughput and vice-versa.

To read more, please visit: https://buildatscale.tech/transaction-isolation-level-in-innodb/

How to structure your code in django

Rahul Mishra — Thu, 29 Apr 2021 07:06:27 +0000

https://medium.com/healthify-tech/django-things-i-wish-i-knew-before-using-it-part-i-5af75beb1480