sqlalchemy: guessing of parameter style in logging / exceptions fails for positional params plus array parameter
sqlalchemy/sql/util.py#478
def __repr__(self):
if isinstance(self.params, list):
typ = self._LIST
ismulti = self.params and isinstance(
self.params[0], (list, dict, tuple)
)
elif isinstance(self.params, tuple):
typ = self._TUPLE
ismulti = self.params and isinstance(
self.params[0], (list, dict, tuple)
)
I’m not sure but as I suppose ismulti is used to make a difference between usual single queries and “multiple” inserts or replaces etc to log that “multiple” data correctly.
But ismulti==True also in case when the first parameter of the usual single query is a list. And in that case sqlalchemy throws TypeError: '...' object is not iterable when logging next non-iterable parameters of the that query.
The simple example to reproduce the bug is a query like
select * from smth where id in :set and created>:yesterday
As I’m olny trying this ORM, not sure how to fix it 😦 . May be there are other attributes to determine “multiple” queries ?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 18 (11 by maintainers)
i might make the change more aggressive in 1.4. for 1.3 just looking to not break things
what it’s doing is being passed whether or not the query is an “executemany” or not from the outside. since this is not always known, it still does the “guess” if executemany wasn’t passed in, but ideally it would always be passed in and that whole guessing logic can be removed. once it knows true/false for that, then it can repr appropriately. your test case is one where it detects “executemany” style when it’s not.
Mike Bayer has proposed a fix for this issue in the rel_1_3 branch:
pass executemany context to _repr_params https://gerrit.sqlalchemy.org/1509
Mike Bayer has proposed a fix for this issue in the master branch:
pass executemany context to _repr_params https://gerrit.sqlalchemy.org/1508