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

Unicode engine with repr(engine) #130

Closed
elbenfreund opened this issue Apr 25, 2016 · 0 comments
Closed

Unicode engine with repr(engine) #130

elbenfreund opened this issue Apr 25, 2016 · 0 comments
Labels
Milestone

Comments

@elbenfreund
Copy link
Collaborator

elbenfreund commented Apr 25, 2016

There seems to be an issue when calling repr(engine) on an sqlalchemy engine instance like we do here
If the engine is an sqlite one and the path contains unicode we end up with an UnicodeError.

[tests/conftest.py:76: in runner
    return CliRunner().invoke(hamster_cli.run, args, catch_exceptions=False, **kwargs)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/testing.py:279: in invoke
    prog_name=self.get_default_prog_name(cli), **extra)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/core.py:696: in main
    rv = self.invoke(ctx)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/core.py:1057: in invoke
    Command.invoke(self, ctx)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/core.py:889: in invoke
    return ctx.invoke(self.callback, **ctx.params)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/core.py:534: in invoke
    return callback(*args, **kwargs)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/decorators.py:57: in new_func
    obj = ctx.ensure_object(object_type)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/click/core.py:456: in ensure_object
    self.obj = rv = object_type()
hamster_cli/hamster_cli.py:119: in __init__
    super(Controler, self).__init__(lib_config)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/hamsterlib/lib.py:67: in __init__
    self.store = self._get_store()
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/hamsterlib/lib.py:88: in _get_store
    return cls(self.config)
../../.virtualenvs/hamster_cli_py27/lib/python2.7/site-packages/hamsterlib/backends/sqlalchemy/storage.py:84: in __init__
    self.logger.debug(_("Engine '{}' created.".format(engine)))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <[UnicodeEncodeError("'ascii' codec can't encode characters in position 67-76: ordinal not in range(128)") raised in repr()] SafeRepr object at 0x7fdb0399b248>

    def __repr__(self):
>       return 'Engine(%r)' % self.url
E       UnicodeEncodeError: 'ascii' codec can't encode characters in position 67-76: ordinal not in range(128)
](url)
@elbenfreund elbenfreund added this to the 0.11.0 milestone Apr 25, 2016
elbenfreund added a commit that referenced this issue Jun 28, 2016
Running python 2, it apears SQLAlchemy is not fully capable to handle
unicode strings as urls. While they can be passed and will be processed
(correctly as far as we can tell) there are issues with 'representing'
an ``Engine`` or ``sqlalchemy.engine.url.URL``. As far as we understand,
their repr() call will naivly construct a str from its various
components. If any of those substrings (like the URL) happens to be an
unicode string, this will fail if it can not be ascii-decoded.
SQLAlchemy should propably call repr(url) instead.

For now, this commit just avoids the problem entirely by amending the
triggering log message not to render a string representation of the
created engine. A proper solution would probably be to write a custom
wrapper function that handles Engine representation properly.

Also, a test that triggers the origianl offending behaviour has been
added, so any regression should be easier to find.

Closes: #130
@elbenfreund elbenfreund removed the Ready label Jun 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant