-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ForeignKey reverse relations do not take into account configured schema (postgres). #287
Comments
I've duplicated your relations test using separate schemas here: I get a different error:
|
The error is caused by using two separate metadata that don't know about each other. So each table is registered in a separate namespace. To achieve what you want you would probably have to have a way of declaring schema on a model level rather than on a metadata level. I know you can have multiple databases/schemas but usually, the use case is to query them separately (one at a time). Does the functionality you want actually work in sqlalchemy? I recall something about |
What was intresting is that the specifically defined relation worked, only the generated reverse relation did not work. I haven't tried with just sqlalchemy. For now I have worked around not having this, but I expect I'll come back to it. |
@collerek @naturalethic Hi! |
Describe the bug
When using postgres with multiple schemas, while the direct relation with ForeignKey works, the reverse relation fails with an error:
To Reproduce
Define a relation between schemas. That is, configure in the MetaData class for one entity to be of one schema, and the related entity of antoher.
Under this scenario,
bear.alpaca
succeeds,alpaca.bears.all()
will fail.Expected behavior
That the reverse relation executes a query taking the related tables schema into account.
Screenshots
N/A
Versions (please complete the following information):
ormar
version 0.10.5pydantic
version 1.8.2fastapi
version N/AAdditional context
N/A
The text was updated successfully, but these errors were encountered: