-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
Fix inserts in through tables #361
Conversation
Could we please merge this PR? |
@toluaina have you had any time to look into this? This workaround has been working in production for more than a month with no issues. |
#413 should fix this issue |
Apologies for the delay. The latest release 2.5 should fully address this. |
is anyone getting error |
Not me, for now it works fine. I'll keep you updated if issues arise.
…On Thu, Feb 2, 2023, 12:09 AM nsupegemini ***@***.***> wrote:
is anyone getting error RuntimeError: Required materialized view columns
not present on _view. Please re-run bootstrap. after upgrading to 2.5
version?
—
Reply to this email directly, view it on GitHub
<#361 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFZBVK6VNQQJ5NFX6ZT5LDWVMQOBANCNFSM6AAAAAARNKZ4GA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Hi @nsupegemini |
Thank you @vinhnxv Thank you for the solution. It worked. Sorry for late reply. Is this view created by PGSync? |
This fixed the issue for my case, and could probably also fix:
#142
#264
#321
My simplified DB:
My schema.json
When the code reaches this point after an insert on the through table I get:
At that point it fails with this error:
I've tried all kinds of configurations, specifying the foreing_keys, transformations, specifying nested types, but nothing works, I ended up debugging and working this out but I think there is an underlying issue.
This bug happens in Postgres 14 and AWS RDS when I use a through table in a child and insert directly into it.
The tests seem to run cleanly, but this workaround is far from ideal.
Please also check this line and downwards, looks like dead code to me, it seems you are adding all through tables to self.tree.tables so I think that block should probably never be reached. Also note that I think this is just a workaround, if I use
filter[node.parent.table]
instead offilter[node.parent.name]
I will get an exception on insert:I tried to reproduce this bug with the book example with no luck.
What I can see is that when debugging the _insert_op method is the foreign_keys dictionary generated is not what the code expects.
I hope this can serve to narrow down the issue and fix it! Cheers.