Django: Decouple Excerpt

Aravinda S Holla — Sat, 05 Dec 2020 04:28:06 +0000

In the Court of Judiciary, the loser is the one who has won, dead is the one who has lost. - Boothayyana Maga Ayyu, Kannada Cinema.

In real-world projects, sensitive and important data such as server IP address, credentials, etc, must be kept secret as much as possible.

For doing so, we have lots of tools, utilities, packages, etc. But while using such a facility, there may be problems of another kind.

Let's have an illustration.

Django Twangy:

The cookie-cutter tool is a commonly used project template starter. And provides us with a clean folder structure, .envs, for storing the data.

These data are supplied to python code via environment variables, something like:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'ecommerce-portal',
        'USER': 'postgres',
        'PASSWORD': os.environ.get('DATABASE_PASSWORD'),,
        'HOST': os.environ.get('DATABASE_HOST', default='localhost'),
        'PORT': '5432',
    }
}

Here secrets such as DATABASE_PASSWORD, DATABASE_HOST can be stored at .envs.

The Case:

In the above scenario, if Supervisor (a process control system) is used: While restarting sub-processes,

sudo supervisorctl restart ecommerce_celery

the result maybe something like:

ecommerce_celery: ERROR (not running)
ecommerce_celery: ERROR (spawn error)

If subprocess worker log is checked:

django.db.utils.OperationalError: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

supervisor runs outside the context of the virtual environment, detached from environment variables
In the above error case, the supervisor has not received the database name to connect.

A possible try is to pass the database name in the config file as an environment variable, like:

environment = DATABASE_HOST="255.254.253.252", .....

at /etc/supervisor/conf.d/ecommerce_celery.conf.

This does not seem to work but continues to persist with the same error.

Saviour:

python-decouple is a smart and simple solution that solves the above problem in a painless manner.

from decouple import config

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'ecommerce-portal',
        'USER': 'postgres',
        'PASSWORD': config('DATABASE_PASSWORD'),,
        'HOST': config('DATABASE_HOST', default='localhost'),
        'PORT': '5432',
    }
}

The restart does not produce the errors but runs successfully.

Django REST Framework: The powers of a Serializer (1)

Aravinda S Holla — Sun, 29 Nov 2020 12:26:46 +0000

Water has been taken for granted. - Jan Eliasson

DRF's Serializer has been proved to be a killing feature.

Here I am going to share details of updating a Foreign key object data while updating a reverse relation object using serializer.

The point here is that, while we usually use foreign key fields in the serializer for reading operation, we can also use them to write operations.

Update FK object data:

Let's consider a scenario.

Where we have an account, to which loan applications can be submitted. While approving an application, we need to collect the approved_amount and reason.

class Account(models.Model):
    account_number = models.CharField(max_length=255)
    approved_amount = models.PositiveIntegerField(default=0)
    reason = models.CharField(max_length=255, null=True, blank=True)

    def __str__(self):
        return self.account_number


class LoanApplication(models.Model):

    class Status(models.TextChoices):
        SUBMITTED = 'SUBMITTED', 'Submitted',
        REJECTED = 'REJECTED', 'Rejected'
        APPROVED = 'APPROVED', 'Approved'

    account = models.ForeignKey(Account, on_delete=models.CASCADE)
    status = models.CharField(
        max_length=255, choices=Status.choices, default=Status.SUBMITTED)

    def __str__(self):
        return str(self.account)

The above requirement shall be done using only one API call.

As shown in the above code shots, we have approved_amount and reason in the Account model, whereas approval shall be done to the LoanApplication object.

Let's see how the serializer tackles the above problem.

As in the below shots, while approval, we collect the amount and reason in the same API. In serializer, just before updating LoanApplication, we separate Account data and update to the appropriate account, then proceed to update the loan application.

class AccountSerializer(serializers.ModelSerializer):

    class Meta:
        model = Account
        fields = '__all__'


class LoanApplicationSerializer(serializers.ModelSerializer):
    approved_amount = serializers.IntegerField(
        source='account.approved_amount')
    reason = serializers.CharField(source='account.reason')

    class Meta:
        model = LoanApplication
        exclude = ('account',)

    def update(self, instance, validated_data):
        account_data = validated_data.pop('account', None)
        if account_data:
            account_serializer = AccountSerializer(
                instance.account, data=account_data, partial=True)
            account_serializer.is_valid(raise_exception=True)
            account_serializer.save()

        return super().update(instance, validated_data)

DEV Community: Aravinda S Holla