Missing named access to result set

[bustbr]

Hi,

#408 changed the return type for all fetch ops from Mapping to Sequence, because of a change in SQLAlchemy 1.4.

This means Databases doesn't seem to offer any standard way to access the result values by name anymore.
The postgres backend offers a _mapping property and all the other backends are using SQLAlchemy's Row, which means _mapping is also available, but this is not documented as far as I can tell.

In SQLAlchemy the change wasn't intended to remove named access, the returned Row offers the result set as properties instead, like a named tuple, and in SQLAlchemy 2.0 there's a mapping() method on the result.

Could we add a standardized way of accessing the mapping in Databases as well?
Adding the _mapping property to the result set interface would be enough, but maybe there's a better idea.
Another easy way would be to implement __getattr__ on the postgres backend's Record type.

[laukhin]

+1 it breaks a whole database layer for my project. It's really unexpected to have such a drastic interface change from minor release like 0.5.3 -> 0.5.4.

[aminalaee]

Hi,

Yes you're right, this wasn't expected.

I think the reason behind that might be it wasn't a good idea to document a private property like _mappingand now with this change, the private property is the only interface left.

I think a more standardized way to deal with it would be much nicer, but maybe we could have a fix for it out soon and deal with that later?

Feel free to create a PR for it.

[laukhin]

Thank you for the quick response. I've created PR #447 for it, please check it out :)

[aminalaee]

As for the named access to the row result maybe we can do this.

The SQLAlchemy Row already has __getattr__ through BaseRow so if we add it to asyncpg Record then it should be ok for all drivers.

Simple PR for this: https://github.com/encode/databases/pull/448S

[collerek]

Please update to 0.5.5 for an immediate fix.

[bustbr]

thank you.