Find SQLAlchemy Mapped model fields in parent classes

[hrolfurgylfa]

Summary

This solves #4903 by going through the method resolution order and finding all the Mapped fields on it or its parent classes, instead of just looking at the target class itself.

Fixes #4903

Test Plan

Added tests with both a parent class that is an SQLAlchemy model and one that isn't, and thus has to use it as a Mixin to get its Mapped fields.

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D119762949. (Because this pull request was imported automatically, there will not be any future comments.)

[rchen152]

Thanks! This looks close, but I believe the MRO walk is backwards. I'd expect it to start with model, then go through ancestors_no_object in the regular direction, and collect only the names whose first appearance is a Mapped field (to handle attribute overrides).

[hrolfurgylfa]

Thanks! This looks close, but I believe the MRO walk is backwards. I'd expect it to start with model, then go through ancestors_no_object in the regular direction, and collect only the names whose first appearance is a Mapped field (to handle attribute overrides).

Thanks for the review, yep, forgot to consider what happens with overwritten fields. I've now added that to the test, reversed the mro and modified the walk to ignore fields it has already seen.

I also did some cleanup, found a way to skip the loop within loop with flat_map, and fixed the test, I was filtering on User.id for the AdminUser. I think that should still be valid SQLAlchemy, but it is very weird.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[rchen152]

Review automatically exported from Phabricator review in Meta.

[rchen152]

LGTM, thanks!

[meta-codesync]

This pull request has been merged in 69ffdf4.