[Sqlalchemy-tickets] Issue #3713: Add Integer Enum type support (zzzeek/sqlalchemy)

[Михаил Д. <iss...@bi...>]

New issue 3713: Add Integer Enum type support
https://bitbucket.org/zzzeek/sqlalchemy/issues/3713/add-integer-enum-type-support

Михаил Доронин:

There are attempts to do this already.

[https://gist.github.com/shazow/594861](Link URL)

[http://sqlalchemy-utils.readthedocs.io/en/latest/data_types.html#module-sqlalchemy_utils.types.choice](Link URL)

But I think that this should be part of sqlalchemy really.

Probably everybody knows this but I will state the benefits once more:

1. Takes less space in database
2. Provides higher level interface for cases where for the reason #1 INTEGER, TINYINT etc have been used instead of ENUM or VARCHAR where conceptually we are dealling with enum.

Can't really think of everything else right now, but that's should be enough.

I can try to add this functionality. I don't know sqlalchemy internals well enough, but the gist above should help and it's shouldn't be that hard in any case I think.

The main reason I've maid issue instead of creating pull request right away is that I have a questions about implementation.

1. Should we extend existing Enum type or create a new one?
Both ways would work of course, but in the former case would complicate Enum interface a bit (maybe)

So I see it this way

if native_enum param is False then we look if there is additional 'type' param. 'type' can be one of sqlalchemy types suiting Enum or even database specific type like TINYINT or it could be 'auto', in which case sqlalchemy would choose type based on the amount of enum members (like if we have 3 members that it can use something like TINYINT(2)).

Default value for 'type' param would be varchar so old code wouldn't be broken.

Another option is to create a new IntEnum type with similar interface.

Responsible: zzzeek