[storm] psycopg2-2.2, Storm, and ENUMs

James Henstridge james at jamesh.id.au
Mon May 24 16:35:49 BST 2010


On Sat, May 22, 2010 at 3:06 AM, Dan Halbert <halbert at halwitz.org> wrote:
> A slight warning about the new psycopg2 2.2 version, which just came out this month, and which Storm uses to talk to PostgreSQL:
>
> Psycopg2-2.2 now adds explicit casts to strings in places where it did not before.
> To quote its NEWS-2.2 file:
>  "- Fixed problem with PostgreSQL not casting string literals to the correct
>    types in some situations: psycopg now add an explicit cast to dates, times
>    and bytea representations."
>
> This change causes several storm tests to break for type conversion reasons.
>
> I also had a problem because I had been taking a shortcut with ENUM types. I have some PostgreSQL types like:
>
>  CREATE TYPE color AS ENUM ('blue', 'red');
>
> Previously, I was able to cheat a bit and handle columns of this type by using RawStr() and passing the values back and forth as strings. PostgreSQL would implicitly cast the strings to type "color" with no problem.
>
> But now psycopg2 adds a "::bytea" cast to these values, and I get type conversion errors when using RawStr(). So I had to bite the bullet and (continuing the example):
> 1. Create a Color class for use in my own code
> 2. Add psycopg2 adapters for it.
> 3. Add corresponding storm property and variable classes for this new class.
>
> Initially, for convenience, I tried making my Color class be a subclass of str. However, this does not work in Storm, because Storm's psycopg2 code (in postgres.py) treats anything of string type as a string and passes it as bytea (psycopg2.Binary).
>
> So anyway, be forewarned,

The RawStr property type in Storm is really intended for use with
binary data.  Given that the 2.x str type has essentially become the
bytes type in Python 3, I wonder if the psycopg2 changes are treating
it in a similar fashion?

That said, If you are dealing with textual data (which the enumeration
values essentially are), perhaps the Unicode type would have worked
better.  Another option would be the Enum type, which lets you provide
an arbitrary map between Python and database values.

James.



More information about the storm mailing list