Year: 2015

Django REST Framework: Custom Exception Handler

Post author By masnun
Post date November 6, 2015
7 Comments on Django REST Framework: Custom Exception Handler

While using DRF, do you need to handle the exceptions yourselves? Here’s how to do it. First, we need to create an exception handler function like this:

from rest_framework.views import exception_handler


def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    if response is not None:
        data = response.data
        response.data = {}
        errors = []
        for field, value in data.items():
            errors.append("{} : {}".format(field, " ".join(value)))

        response.data['errors'] = errors
        response.data['status'] = False

        response.data['exception'] = str(exc)

    return response

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):

# Call REST framework's default exception handler first,

# to get the standard error response.

response = exception_handler(exc, context)

if response is not None:

data = response.data

response.data = {}

errors = []

for field, value in data.items():

errors.append("{} : {}".format(field, " ".join(value)))

response.data['errors'] = errors

response.data['status'] = False

response.data['exception'] = str(exc)

return response

In the exception handler, we get exc which is the exception raised and the context contains the context of the request. However, we didn’t do anything fancy with these. We just called the default exception handler and joined the errors in a flat string. We also added the exception to our response.

Now, we need to tell DRF to call our custom exception handler when it comes across an exception. That is easy:

Open up your settings.py and look for the REST_FRAMEWORK dictionary. Here you need to add the exception handler to the EXCEPTION_HANDLER key. So it should look something like this:

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.BasicAuthentication',
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    ),


    'EXCEPTION_HANDLER': 'api.utils.custom_exception_handler'
}

REST_FRAMEWORK = {

'DEFAULT_AUTHENTICATION_CLASSES': (

'rest_framework.authentication.BasicAuthentication',

'rest_framework.authentication.SessionAuthentication',

'rest_framework.authentication.TokenAuthentication',

'EXCEPTION_HANDLER': 'api.utils.custom_exception_handler'

}

Django Python

Django: Handling broken migrations

Post author By masnun
Post date November 6, 2015
1 Comment on Django: Handling broken migrations

Often for one reason or another, migrations don’t apply properly and we have to fix them manually. If there’s a faulty migration that throws errors when run, we first have to identify what went wrong. Very often on MySQL, we see half applied migrations (probably because MySQL doesn’t have transactions?). In this case we need to do the other half ourselves.

We can easily connect to the database prompt by typing the dbshell command.

python manage.py dbshell

1	python manage.py dbshell

The command opens the shell for the respective database engine using the configurations provided in the settings file. That is you don’t have to remember the username or password for the database connection.

Now you have to fix the issues and then you can try running the migration again. In case it fails again, you should alter the database to match the state the migration would have created. For example, if the migration was supposed to alter a column from store_type to store_type_id (from a char field to foreign keys), you have to manually run the query, something like:

ALTER TABLE api_store CHANGE store_type store_type_id INT(11);

1	ALTER TABLE api_store CHANGE store_type store_type_id INT(11);

Then you have to fake the migration. When a migration is run, Django stores the name of the migration in a table. It helps track which migrations have already run and which needs to be run. When we fake a migration, Django stores the faked migration name in that table without actually running it. If we don’t do this, when we next run migrate command, Django will try to run this migration again and fail.

This is how we fake it:

python manage.py migrate --fake

1	python manage.py migrate --fake

You can also specify one particular migration when you have multiple migrations running.

python manage.py migrate --fake <appname> <migration_name>

1	python manage.py migrate --fake <appname> <migration_name>

Python

Python: Writing custom log handler and formatter

Post author By masnun
Post date November 4, 2015
6 Comments on Python: Writing custom log handler and formatter

Log Handlers dictate how the log entries are handled. For example FileHandler would allow us to pipe our logs to a file. HTTP Handler makes it possible to send the logs over HTTP to a remote server. We can write our own log handlers if we need to customize the way our logs are processed. Writing a custom handler is pretty simple. We have to subclass it from logging.Handler class and must define the emit method. This method is called with each log record so we can process it.

Here’s an exmaple of a custom log handler which POSTs the logs to a remote server using the popular requests library.

class RequestsHandler(Handler):
    def emit(self, record):
        log_entry = self.format(record)
        return requests.post('http://example.com:8080/',
                             log_entry, headers={"Content-type": "application/json"}).content

class RequestsHandler(Handler):

def emit(self, record):

log_entry = self.format(record)

return requests.post('http://example.com:8080/',

log_entry, headers={"Content-type": "application/json"}).content

Now we have our custom handler that will post the logs to another server. What if we want to send the message in a specific format? We write our custom formatter. A formatter has a format method which gets the record. We can take the record and return a message formatted according our need. Here’s an example for logstash format:

class LogstashFormatter(Formatter):
    def __init__(self, task_name=None):
        self.task_name = task_name

        super(LogstashFormatter, self).__init__()

    def format(self, record):
        data = {'@message': record.msg,
                '@timestamp': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%S.%fZ'),
                '@type': 'IronWorker'}

        if self.task_name:
            data['@task_name'] = self.task_name

        return json.dumps(data)

class LogstashFormatter(Formatter):

def __init__(self, task_name=None):

self.task_name = task_name

super(LogstashFormatter, self).__init__()

def format(self, record):

data = {'@message': record.msg,

'@timestamp': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%S.%fZ'),

'@type': 'IronWorker'}

if self.task_name:

data['@task_name'] = self.task_name

return json.dumps(data)

So we have got ourselves a custom log handler and a formatter. But how do we use them? Here’s a short code snippet:

    def __init_logging(self):
        self.logger = logging.getLogger(self.logger_name.upper())
        self.logger.setLevel(self.logging_level)

        handler = RequestsHandler()
        formatter = LogstashFormatter(self.logger_name.upper())
        handler.setFormatter(formatter)
        self.logger.addHandler(handler)

def __init_logging(self):

self.logger = logging.getLogger(self.logger_name.upper())

self.logger.setLevel(self.logging_level)

handler = RequestsHandler()

formatter = LogstashFormatter(self.logger_name.upper())

handler.setFormatter(formatter)

self.logger.addHandler(handler)

Recent Posts

Recent Comments

Archives

Categories