Upgrading to Django 3.2 and fixing DEFAULT_AUTO_FIELD warnings

weplayinternet — Fri, 09 Apr 2021 07:50:28 +0000

When you define a model in Django without specifying a primary key, Django will automatically create a primary key for you. The primary key is set to be an integer. If you want to override the field type, you can do so on a per model basis.

Starting in Django 3.2, you can now customise the type of the automatically created primary key in your settings.

Starting new projects in Django 3.2, the default type for primary keys is set to a BigAutoField which is a 64 bit integer. However, earlier versions set the type of implicit primary keys to be integers.

This means that when you upgrade to 3.2, you will start to see warnings about the fact that you do not have an explicitly defined primary key type. Satisfying Django's requirements for an explicitly set primary key type is easy enough, but you also need to choose whether or not you want to upgrade your primary key field types from integer to 64 bit integer.

Having upgraded to 3.2, the suggestion in the official docs is to run

python -Wa manage.py test

You should see the warning and the hint to configure a DEFAULT_AUTO_FIELD

WARNINGS:
blog.BlogPost: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
    HINT: Configure the DEFAULT_AUTO_FIELD setting or the BlogConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.

There are a few ways to fix this. Broadly speaking they fall into two categories - those that do not require a migration and those that do.

No migrations please

If you want the simplest upgrade path without migrations, you'll need to tell Django to set the DEFAULT_AUTO_FIELD to AutoField which is, under the hood, an IntegerField. There are a few places you can do this

Configure DEFAULT_AUTO_FIELD in settings

Open your project's settings.py and add a new line at the bottom of the file

DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'

Setting on a per app basis

If you prefer to set your field type on a per app basis rather than for the whole project, you can specify this in apps.py. You might want to do this if you want a different auto field type per app. For a hypothetical project with a blog app, adding the default_auto_field line in apps.py will work:

from django.apps import AppConfig

class BlogConfig(AppConfig):
    default_auto_field = 'django.db.models.AutoField'
    name = 'blog'

Migrations

If you don't mind creating and running migrations, then you can embrace the new BigAutoField. Again, there are a few ways to achieve this:

Configure DEFAULT_AUTO_FIELD in settings to use BigAutoField

Open your project's settings.py and add the following to the bottom:

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

You'll then need to create and run a migration to update your database to use the new field type. The migrations will alter the id field on your models. To create and run migration in a hypothetical application named blog, you'd run the following commands

> python manage.py makemigrations blog

> python manage.py sqlmigrate blog <migration_number>

Set default_auto_field to BigAutoField on a per app basis

As above, you can configure the setting on a per app basis, so in apps.py, you can set the default_auto_field to BigAutoField:

from django.apps import AppConfig

class BlogConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'my_app'

and again create and run migrations for your app.

Set AutoField or BigAutoField on a per model basis

If you prefer even more fine grained control, you can set a per model id field. A blogging app might have a BlogPost model. You can explicitly set an id field on each model.

In a hypothetical blog application you would modify blog/models.py

class BlogPost(models.Model):
    id = models.BigAutoField(primary_key=True)
    # ...other fields

If you prefer, you can instead subclass a common base model. Perhaps it saves you some typing if you have a large number of models. In a hypothetical blog application, you would define a common base model and then inherit from it in each model

from django.db import models

class CommonBaseModel(models.Model):
    id = models.BigAutoField(primary_key=True)

    class Meta:
        abstract = True


# Create your models here.
class BlogPost(CommonBaseModel):
   # ...other fields

In either of the two previous examples, you can use AutoField instead of BigAutoField if you prefer to keep your primary key as an integer. You still need to make and run migrations to be fully up to date though, because you've changed your model definitions.

Summary

Django 3.2 allows developers to customise the field type used when creating automatic primary keys. Upgrading means you'll Django will warn you that you do not have the field type set. To silence the warnings, you need to set the default auto field at a project, app, or model level.

About the simplest thing a Ruby dev can do with Docker

weplayinternet — Fri, 31 Jul 2020 08:37:46 +0000

Docker, in the beginning, can be overwhelming. Tutorials often focus on creating a complex interaction between Dockerfiles, docker-compose, entrypoint scripts and networking.

It can take hours to bring up a simple Rails application in Docker and I found that put me off the first few times I tried to play with it.

I think a rapid feedback loop is essential for playing with a piece of technology.

If you've never used Docker before, then this is the perfect post for you. I'll start you off on your docker journey and with a few simple commands, you'll be in a Docker container, running ruby interactively.

You'll need to install Docker. On a Mac, I prefer to install Docker Desktop through homebrew:

brew cask install docker

If you're running Linux or Windows, read the official docs for install instructions.

On your Mac, you should now have a Docker icon in your menu bar. Click on it and make sure it says "Docker desktop is running".

Now open a terminal and type the following:

$ docker run -it --rm ruby:2.7.1-buster

You should be dropped into an irb session:

> docker run -it --rm ruby:2.7.1-buster
irb(main):001:0> puts "Hello from inside a Docker container"
Hello from inside a Docker container
=> nil
irb(main):002:0>

That should return you to your normal command prompt.

It doesn't look like you've done much - bringing up an irb session isn't groundbreaking. You can do the same by typing irb at your usual prompt.

Breaking down the command used:

docker run runs a command in a new container

-it these two options that tell docker to run in interactive mode and to allocate a pseudo-TTY

--rm instructs docker to automatically delete the container when we exit

ruby:2.7.1-buster theimage that we want to run.

You'll notice that none of those commands actually tried to execute irb to run the Ruby REPL. So how did we end up in an irb session?

The answer is that the Docker image we used defined a default step for us to start irb.

DEV Community: weplayinternet