Postgres ENUM types in Django
-
Comments:
- here.
Postgres has the ability to create custom types. There are several kinds of CREATE TYPE
statement:
- composite types
- domain types
- range types
- base types
- enumerated types
I’ve used a metaclass that is based on Django’s Model classes to do Composite Types in the past, and it’s been working fairly well. The current stuff I have been working on made sense to use an Enumerated Type, because there are four possible values, and having a human readable version of them is going to be nicer than using a lookup table.
In the first iteration, I used just a TEXT column to store the data. However, when I then started to use an enum.Enum
class for handling the values in python, I discovered that it was actually storing str(value)
in the database, rather than value.value
.
So, I thought I would implement something similar to my Composite Type class. Not long after starting, I realised that I could make a cleaner implementation (and easier to declare) using a decorator:
@register_enum(db_type='change_type')
class ChangeType(enum.Enum):
ADDED = 'added'
CHANGED = 'changed'
REMOVED = 'removed'
CANCELLED = 'cancelled'
ChangeType.choices = [
(ChangeType.ADDED, _('hours added')),
(ChangeType.REMOVED, _('hours subtracted')),
(ChangeType.CHANGED, _('start/finish changed with no loss of hours')),
(ChangeType.CANCELLED, _('shift cancelled')),
]
Because I’m still on an older version of Python/Django, I could not use the brand new Enumeration types, so in order to make things a bit easier, I then annotate onto the class some extra helpers. It’s important to do this after declaring the class, because otherwise the attributes you define will become “members” of the enumeration. When I move to Django 3.0, I’ll probably try to update this register_enum
decorator to work with those classes.
So, let’s get down to business with the decorator. I spent quite some time trying to get it to work using wrapt, before realising that I didn’t actually need to use it. In this case, the decorator is only valid for decorating classes, and we just add things onto the class (and register some things), so it can just return the new class, rather than having to muck around with docstrings and names.
from psycopg2.extensions import (
new_array_type,
new_type,
QuotedString,
register_adapter,
register_type,
)
known_types = set()
CREATE_TYPE = 'CREATE TYPE {0} AS ENUM ({1})'
SELECT_OIDS = 'SELECT %s::regtype::oid AS "oid", %s::regtype::oid AS "array_oid"'
class register_enum(object):
def __init__(self, db_type, managed=True):
self.db_type = db_type
self.array_type = '{}[]'.format(db_type)
self.managed = managed
def __call__(self, cls):
# Tell psycopg2 how to turn values of this class into db-ready values.
register_adapter(cls, lambda value: QuotedString(value.value))
# Store a reference to this instance's "register" method, which allows
# us to do the magic to turn database values into this enum type.
known_types.add(self.register)
self.values = [
member.value
for member in cls.__members__.values()
]
# We need to keep a reference to the new class around, so we can use it later.
self.cls = cls
return cls
def register(self, connection):
with connection.cursor() as cursor:
try:
cursor.execute(SELECT_OIDS, [self.db_type, self.array_type])
oid, array_oid = cursor.fetchone()
except ProgrammingError:
if self.managed:
cursor.execute(self.create_enum(connection), self.values)
else:
return
custom_type = new_type(
(oid,),
self.db_type,
lambda data, cursor: data and self.cls(data) or None
)
custom_array = new_array_type(
(array_oid,),
self.array_type,
custom_type
)
register_type(custom_type, cursor.connection)
register_type(custom_array, cursor.connection)
def create_enum(self, connection):
qn = connection.ops.quote_name
return CREATE_TYPE.format(
qn(self.db_type),
', '.join(['%s' for value in self.values])
)
I’ve extracted out the create_enum
method, because it’s then possible to use this in a migration (but I’m not totally happy with the code that generates this migration operation just yet). I also have other code that dynamically creates classes for a ModelField
and FormField
as attributes on the Enum subclass, but that complicates it a bunch.