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

PhoneNumberType: missing type coercion when binding params for a LIKE statement #560

Open
Ayak973 opened this issue Dec 1, 2021 · 2 comments · May be fixed by #737
Open

PhoneNumberType: missing type coercion when binding params for a LIKE statement #560

Ayak973 opened this issue Dec 1, 2021 · 2 comments · May be fixed by #737
Labels

Comments

@Ayak973
Copy link

Ayak973 commented Dec 1, 2021

When we want to use a filter on a column of type PhonenumberType with a like statement, the default behavior produce an SQL
query with a phonenumber constructed with default US region:

SQL produced (sqlalchemy engine echo on):
SELECT phone_number.phone_number FROM phone_number WHERE phone_number.phone_number LIKE %s

Bound values produced (incorrect):
('+1456')

Bound values expected (correct):
('%456%')

Possible workaround: make the type coercion return a string for the like (and notlike) statements. We have subclassed PhonenumberType to bypass this limitation (inspired by the original function from SQLAlchemy):

class PhoneNumberType(sqlalchemy_utils.types.phone_number.PhoneNumberType):
    def coerce_compared_value(self, op, value):
        if op in (like_op, notlike_op):
            return String()
        else:
            return self

Is it possible to add this behavior to the library, or have we missed something ?

OS: Debian 11 bullseye
Python: 3.9.2
SQLAlchemy_utils: 0.37.9

Regards

@kvesteri
Copy link
Owner

Sure, PRs with tests welcome 👍

@kurtmckee kurtmckee added the bug label Apr 21, 2022
@aryadovoy
Copy link

So I still cannot use ilike with PhoneNumberType and get error:

    raise PhoneNumberParseException(getattr(e, "error_type", -1), str(e))
sqlalchemy_utils.types.phone_number.PhoneNumberParseException: (1) (1) The string supplied did not seem to be a phone number.

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

Successfully merging a pull request may close this issue.

4 participants