Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot make db -> python value conversion working with custom SA columns #86

Closed
avanov opened this issue Nov 8, 2015 · 10 comments
Closed

Comments

@avanov
Copy link

avanov commented Nov 8, 2015

The definition:

import logging
import sqlalchemy.types as types
from enum import Enum as PythonEnum

log = logging.getLogger(__name__)

class PythonMappedEnum(types.TypeDecorator):
    """ Implements mapping between Postgres' Enums and Python Enums.
    """
    impl = types.Enum

    def __init__(self, python_enum_type: PythonEnum, **kwargs):
        self.python_enum_type = python_enum_type
        self.kwargs = kwargs
        enum_args = [x.value for x in python_enum_type]
        super(PythonMappedEnum, self).__init__(*enum_args, **self.kwargs)

    def process_bind_param(self, value: PythonEnum, dialect):
        """ Convert to postgres value
        """
        return value.value

    def process_result_value(self, value: str, dialect):
        """ Convert to python value
        """
        log.debug("=====================")
        log.debug("Called")
        for __, case in self.python_enum_type.__members__.items():
            if case.value == value:
                return case
        raise TypeError("Cannot map Enum value '{}' to Python's {}".format(
            value, self.python_enum_type
        ))

    def copy(self):
        return PythonMappedEnum(self.python_enum_type, **self.kwargs)

The calling code (abstract):

result = yield from SAPoolConnection.execute(SATable.select().limit(1))
data = yield from result.fetchone()

When data is processed, the value that corresponds to the custom Enum field is of type str, because the process_result_value() never gets called. But for insert statements, process_bind_param() is called as expected.

@avanov
Copy link
Author

avanov commented Nov 8, 2015

Relevant docs section

@TimNN
Copy link

TimNN commented Mar 5, 2016

I was about to report the same issue (took me a while to track this down).

As far as I can tell, the problem is that aiopg converts the types solely based on the oid of the type reported by postgresql (during my test process_bind_param does also not seem to be called I don't know how conversion happens there).

@TimNN
Copy link

TimNN commented Mar 9, 2016

@asvetlov you seem to be the main maintainer of this project, could you maybe chime in on this issue?

Is this (apart from this issue) a known weakness of aiopg and are there any plans to fix this? Or is there a technical reason that this is (currently) not possible to implement?

@asvetlov
Copy link
Member

asvetlov commented Mar 9, 2016

Guys, honestly I did not try custom types yet, so I don't know where it fails.

Maybe I'll find a time for investigation after fixing #20

@TimNN
Copy link

TimNN commented Mar 9, 2016

Don't feel pressured to fix this as soon as possible! I was just curious what the status was on this issue since there has never been an "official" response to this issue.

@serg666
Copy link

serg666 commented Apr 3, 2016

Have the same problem. process_bind_param() gets called, but process_result_value() never gets called

@serg666
Copy link

serg666 commented Sep 15, 2016

Guys, have any news about this issue? May be it can be fixed?

@asvetlov
Copy link
Member

Nothing new I think.
At least I've failed with fix after couple hours of trying.

vir-mir added a commit to vir-mir/aiopg that referenced this issue Nov 24, 2016
@vir-mir
Copy link
Member

vir-mir commented Nov 24, 2016

Better late than never #217

jettify added a commit that referenced this issue Nov 25, 2016
@jettify
Copy link
Member

jettify commented Nov 25, 2016

implemented in #217

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants