build(deps): switch to sqlalchemy 1.4

[PrettyWood]

Sqlalchemy 1.4 is out with some breaking changes (e.g. RowProxy got removed in favor of Row or the removal of row.values() in favor of row._mapping.values())

closes #298 and closes #348

[PrettyWood]

I would like your insight on this matter.

For postgres, row.values() was still working thanks to this Record class but for all other backends we now need to do row._mapping.values() with sqlalchemy >= 1.4

Do we want to:

1. keep values() only for postgres
2. keep values() for all backends and we can attach the deprecated property to the sqlalchemy.Row class
3. let it like this and mimic sqlalchemy API also for postgres

Thanks for this very nice lib!

[ansipunk]

imo It'd be better to keep row.values() for all backends since looking at test changes I can see that row.keys() is still present so row._mapping.values() would bring an inconsistency.

Although it's sorta weird they kept row.keys() but got rid of row.values() in favor of row._mapping.values(). I think you could try row._asdict() as suggested here in SQLAlchemy issue related to 1.4.

SQLAlchemy documentation says row.keys() is deprecated in favor of row._mapping() so I suppose you have to add row.mapping() for all backends.

[PrettyWood]

Hmmm I don't really want to add row.values() for all backends since it would need some monkeypatching or wrapper around the SQLAlchemy objects.
I reckon the idea of databases is to keep things simple and to stay close to SQLAlchemy when possible.
This is why I went with updating postgres backend only to mimic SQLAlchemy behaviour.
But honestly I don't have a strong opinion on this so if people really want values(), keys() back, we can recreate the wrapper RowProxy

[ansipunk]

My bad, I started my comment with keep since that inconsistency was triggering me, although after reading SQLAlchemy's changelogs and docs I immediately changed my mind about keeping values but did not change the original paragraph.

I do agree with decision to keep the API as close to SQLAlchemy's as possible.

Just that test having both row.values and row._mapping.keys misled me.

[uSpike]

setup.py needs to be updated to specify install_requires=["sqlalchemy>=1.4,<2", ... or a similar constraint.

[tomchristie]

New release 0.4.3 to properly pin SQLAlchemy until this PR is resolved. https://pypi.org/project/databases/

(This PR should update the pin to <1.5, so we don't get bitten again.)

[PrettyWood]

@tomchristie do we want to support both 1.3 and 1.4 or 1.4 only?

[tomchristie]

Ideally both, at least for a time. (But if that was really awkward I guess we could consider just 1.4, with some clear notes for users on which older version of databases to use for 1.3 etc)

[PrettyWood]

@tomchristie Ok no problem. Is it ok if I update CI pipeline to run all tests with both versions?

[ansipunk]

I guess dropping support for 1.3 is okay since pip 's new dependency resolver would automatically download an older version of databases if the user's environment requires SQLAlchemy 1.3.

An ugly solution to support both 1.3 and 1.4 can be seen here in SQLAlchemy-Utils 0.37.

[tomchristie]

@Euromance Fair point. I'm okay with requiring 1.4+ then.

[PrettyWood]

Cool! I'll get back on it next Thursday when I have more time

[ansipunk]

I guess you could also test that deprecated methods throw their warnings

[PrettyWood]

@Euromance Yes it was planned thanks 👍 I first wanted to have your feedback on the interface. Glad we agree! Coverage should be good now

[nikolayanguelov]

Do you guys have any update on the ETA on when this might get merged and released to the public?

Thank you!

[pvicente]

Hi, is there any plan to merge this PR? When are you planning to do a release with sqlalchemy >= 1.4 support? 🙏🏼

[tomchristie]

@PrettyWood If you'd like to get this in then let me know and can add you to the maintainers team, and walk you through the release process.

[PrettyWood]

With pleasure @tomchristie!

[tomchristie]

@PrettyWood - Okay, I've sent you an invite. I'll leave getting this reviewed/merged/conflict resolved/whatever up to you - tho let us know if you need anything. Then once that's done let's walk through how you can roll a release.

[PrettyWood]

@tomchristie I rebased on master. I'll wait for a review from a member. If everything is fine, I feel like the release process is straightforward (PR to bump version with changelog update + tag that triggers github worfklow to publish on pypi). Am I missing something?

[ghost]

Is this ready to be merged? Thank you!

[Feijo]

I am also waiting for this release

[aminalaee]

@PrettyWood Do you want to make any other changes or are you waiting for more reviewers?

[PrettyWood]

Hi @aminalaee
I don't plan to add anything more. If we feel like 1 review is enough then we can merge :)

[aminalaee]

Hi, @PrettyWood
I did go over this again and everything looks good. I think we can merge this and prepare the release #370