-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Computed relationships don't support Nested Embedding #2530
Comments
This was already reported in #2455 and fixed in #2519. Not released, yet. You can expect a new pre-release in the next couple of days (currently fixing a few other bugs as well) and probably a patch release soon after. @steve-chavez WDYT? |
Yeah, a patch release sounds good! |
@wolfgangwalther There's a problem with the patch release. See the latest prelease notes, the On nikita-volkov/hasql-pool#22 seems they're thinking to restore the timeout. I guess we have these options for a patch release:
1 would be misleading, 2 might take longer, I think we should do 3. WDYT? (I must say #2444 is critical for heavy traffic, it's a great improvement.) |
I think you misread that thread. It's about forcing the acquisition timeout, but there's nothing about introducing the idle timeout again. I don't think 2 is an option, I don't see the idle timeout coming back. This has been taken out on purpose for some major simplification of hasql-pool. There's two things that are possibly breaking about removing the
While there is nothing that we can do about the second point, it's also nothing that stops people from upgrading. So I'm tempted to mark that as a "change" instead of a "breaking change". That means the next release would not be a patch release, but a minor release would be ok. We need that anyway, because That is as long as keeping the config option in a config file, environment variable or database setting will not break anything. But that should be fine, I'll just add some tests to confirm that non-existing config options don't break. |
Aargh 🤦♂️, yes you're right. Many thanks for clarifying that 🙏 On a separate note, we should have a default for the acquisition timeout. Under heavy traffic I've been seeing a similar effect to #2490 and the timeout makes it a constant CPU usage. Will open a PR for this. |
I have verfied the offical release today, many thanks for your quick support. |
Environment
Description of issue
I am trying to upgrade PostgREST from version 6.0.2 to latest 10.0.0, as mentioned in the release note for 10.0.0, thre is a breaking change:
we have tables which can't fullfill this requiremnt and it is not easy to fix by changing tables, so I try to solve it by Computed relationships. consider following example database:
SQL script
Response
However it seems that Computed relationships can't support Nested Embedding:
http://localhost:3000/actors?select=id,name,films:actor_to_film_map(id,directors(id,name),title)
404
{
"code": "42P01",
"details": null,
"hint": null,
"message": "missing FROM-clause entry for table "films""
}
Without Computed relationships, everything works correctly
http://localhost:3000/actors?select=id,name,films(id,directors(id,name),title)
Expected Response
So is this the limiation of Computed relationships? is there any workaround for it?
Thanks.
The text was updated successfully, but these errors were encountered: