ResultProxy doesn't respect keys defined at Table object

Issue #2392 resolved
Andrey Popp created an issue

Please see test case:

from sqlalchemy import create_engine, MetaData, Table, Column, Integer

e = create_engine("sqlite://")
m = MetaData(bind=e)
t = Table("t", m, Column("a", Integer, key="b"))
m.create_all()

e.execute(t.insert().values(b=1))
print [for x in e.execute(t.select())](x.b)

and execution result:

Traceback (most recent call last):
  File "test.py", line 9, in <module>
    print [for x in e.execute(t.select())](x.b)
  File "/Users/andreypopp/Workspace/zvq/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 2667, in _key_fallback
    expression._string_or_unprintable(key))
sqlalchemy.exc.NoSuchColumnError: "Could not locate column in row for column 'b'"

While I think that that should work fine and return [1](1).

Comments (10)

  1. Mike Bayer repo owner

    workaround for now

    [x[t.c.b](x[t.c.b) for x in e.execute(t.select())]
    

    this could be seriously backwards incompatible so at least for 0.8.

  2. Mike Bayer repo owner

    part of a patch. this will be very tricky, give #918 another look to see if it has anything to offer here

  3. Mike Bayer repo owner

    adding support for very long keys. Some behavior within test_labels has been broken until now, so might want to break this into a separate issue, possibly for 0.7.

  4. Mike Bayer repo owner
    • changed milestone to 0.7.6

    the change in precedence will be #2397. For this ticket we will add the ".key" to the "alternate" name list, which thanks to the changes in #2396, will not clobber existing column names and shouldn't break compatibility, except for an application that relies upon .key not being present in a row for some reason.

  5. Log in to comment