PG’s ENUM type still presents some complexities that we haven’t fully smoothed
over in Alembic though these issues can all be worked around.
On my end I use plain CHAR columns for enums even on PG.
On May 5, 2014, at 2:43 PM, Darin Gordon <dar...@gmail.com> wrote:
> This post is almost a year old. How relevant are the issues discussed in
> this thread to SQLAlchemy 9.3? I was intending to use your declarative enum
> recipe posted from '11.
>
> -Darin
>
>
> On Wednesday, June 5, 2013 10:35:07 AM UTC-4, Michael Bayer wrote:
>
> On Jun 5, 2013, at 6:13 AM, Jan Wąsak <jhn...@gmail.com> wrote:
>
> >
> > I managed to "FIX" this by overriding the create method on the DeclEnumType
> > like so:
> >
> > class DeclEnumType(SchemaType, TypeDecorator):
> > def __init__(self, enum):
> > self.enum = enum
> > self.impl = Enum(
> > *enum.values(),
> > name="ck%s" % re.sub(
> > '([A-Z])',
> > lambda m: "_" + m.group(1).lower(),
> > enum.__name__)
> > )
> >
> > ...
> > ...
> >
> > def create(self, bind=None, checkfirst=False):
> > """Issue CREATE ddl for this type, if applicable."""
> > super(DeclEnumType, self).create(bind, checkfirst)
> > t = self.dialect_impl(bind.dialect)
> > if t.impl.__class__ is not self.__class__ and isinstance(t,
> > SchemaType):
> > t.impl.create(bind=bind, checkfirst=checkfirst)
> >
> > This way my ```t``` is the {Enum} ck_client_came_from type (I'm guessing
> > the implied type for the DeclEnum abstraction) and the create statement
> > gets emitted like so:
>
> yeah that is probably the correct workaround for this one.
>
> >
> >
> > 1. Does what I did make any sense whatsoever? Is the Declarative Enum from
> > the recipe meant to be created explicitly this way? Your code is very
> > descriptive and I THNIK I get the concept of implied types but honestly I
> > am kind of a dog in the fog with my "fix" ;)
>
> Postgresql's ENUM type is hugely annoying to me as there are no other objects
> in any other database that follow this really awkward pattern, so the type
> API really has a hard time with it and we get a lot of bug reports about it.
> I'd need to look into the mechanics of SchemaType and TypeDecorator more
> deeply in order to get them to play better together so that workarounds like
> this arent necessary.
>
>
> > 2. I can get the exact same effect if I just tell my migration to use my
> > ScopedSession and Base and say: Base.metadata.create_all() in the run
> > online migrations routine. Is that the preferred way to run migrations
> > online when using the (oh-so-awesome) ORM from SQLAlchemy?
>
> Well if you aren't in alembic then yes, that system will emit events that I
> think the SchemaType is taking advantage of. Ideally all of these systems
> could be improved a bit.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy-alembic" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy-alembic+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy-alembic" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy-alembic+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
