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
Restart required for detecting table relations on schema change #475
Comments
This was fixed by restarting your postgrest server, correct? If so I'll rename this issue to discuss ways for PostgREST to detect schema changes. |
Restarting PostgREST has fixed my issue indeed. But honestly, before I consider this resolved, I'd love to see some notes on the documentation that makes this (probably temporary) side effect evident to the users. |
I'd love your help with the docs if you could. |
Here are the options I can see for handling schema change.
This last option is really nice. Ideally we can have postgrest set it up without any admin intervention. Any options or pros/cons I'm missing? |
If you number the options:
The options 2 and 4 seem worse than current behavior, 3 and 5 look OK and could probably both be implemented. If we go for option 5, just like for authentication, it would make sense to keep this feature out of |
How about this, on startup have postgrest run this sql: CREATE OR REPLACE FUNCTION public.notify_ddl_postgrest()
RETURNS event_trigger
LANGUAGE plpgsql
AS $$
BEGIN
NOTIFY ddl_command_end;
END;
$$;
DROP EVENT TRIGGER IF EXISTS ddl_postgrest;
CREATE EVENT TRIGGER ddl_postgrest ON ddl_command_end
EXECUTE PROCEDURE public.notify_ddl_postgrest(); Then any schema change will notify on channel The missing piece is that postgrest needs to be able to |
@begriffs There actually is a PR from Leon Smith with that: https://github.com/nikita-volkov/hasql/pull/43/files . I just need to adapt it a little better. |
I think PostgREST produces enough value to be a tad more "invasive" in terms of integration. I mean, when one wants to use PostgREST, he/she may be fine with the fact this component will require an "installation phase" in which it (automatically) creates triggers, tables and whatever else it needs to provide all these non trivial features. I imagine the UX would be something along the lines of:
This way, we can let people opt out the custom triggers and tables if they don't use the advanced features (user management, schema auto-refresh, etc.). But we'd offer a turn-key setup process for the rest of the users (as opposed to "if you want user management, follow this howto.."). |
@sscarduzio I agree, in fact for this feature we just need to create a proc and a trigger so maybe postgrest should just do it without asking. The trigger shouldn't add much of a burden on anyone's db because it triggers only on DDL changes. |
I dont agree :) in order for this to work, the authenticator needs to be granted high privileges, and for what? Compromise security for a small convinience? |
Does it take high privileges to create a function and a trigger? |
I would consider the ability to create procedures and triggers "high privileges". |
Exactly my thought after I posted my previous comment. For example, I am using I currently run |
Well, plot twist: there's not only "production" that counts. |
Also agreed, but development uses extra tools, not installed on the server. I am still suggesting to have a separate, officially sanctioned executable to refresh |
so you suggest I have a while true SIGHUP sleep 1 in my dev env? Is it what you'd propose for tomcat as well? |
In your dev env you create those triggers then listen to notify events with a 10 line script and restart postgrest |
My memories of Tomcat days are slowly fading away, but afaik using a separate process to monitor (e.g. file) changes to reload the server is still pretty much current state of the art:
or more generally |
I still don't understand why it's ok for developers if the developer experience is crap. We have the solution in hand to make this a pleasant thing to use, why pulling back? If you don't want postgrest to retain CREATE permissions, just don't give them. Postgrest will print a warning (as I showed) that schema won't be refreshed. |
New to this - so not sure if this is a silly option- but why not make the notify/advanced features a separate extension for postgres itself? It could be installed separately in its own schema-
Anyway, there are probably cons here that I'm not considering, but just wondering why it's not a part of the discussion. |
OK how about this: postgrest listens for both SIGHUP and a specially named SQL event and reloads the schema in either situation. In production you would send the server a signal, and in development you create an event trigger on In development there would be a snippet of sql that the developer would have to run once in their database which would enable postgrest auto schema change detection. |
Look what's now available! https://github.com/cocreature/hasql-notifications |
Has this been resolved? Seems like if your DB changes, you'll end up with some failed API requests until postgrest has been restarted. Are there any plans to implement the auto-refresh via notifications? |
It hasn't been resolved in full generality, but postgrest does listen for SIGHUP nowadays which will cause it to reload the schema. It's less intrusive than having to restart the server. |
Ah gotcha, so the idea would be that you SSH into your container / dyno and trigger a SIGHUP on that process? |
For now yeah. Having postgrest LISTEN for a specially named event seems feasible for v0.4.1. Once that is implemented we can add a section in the docs about hooking |
Got it, thanks for your help! |
I followed up on the hasql-notifications library which seems to have run into a race condition bug last year. We'll see if that gets resolved, and then it'll be pretty easy to finally get this issue closed. |
@begriffs: JarvusInnovations/lapidus#19 It seems as though it'd be trivial to create a tiny sidecar application that sends SIGHUP to PostgREST if the Haskell library isn't ready yet and just suggest its use in the documentation. Go: Rust: Elixr/Erlang: I think it may be possible to do this with a shell script assuming the user is providing credentials using something |
what is about the part " a specially named SQL event and reloads the schema"? I saw #570 implement the SIGNUP part. for my use case, postgrest run in docker. I run test in another docker. send a signal from one container to another is possible I guess, but not interesting. |
I have an
event_group
table with fieldsgroup_id
andevent_id
referencingevents.id
andgroups.id
respectively.The weird thing is that even if hydrating the event IDs works perfectly:
When I try to do the same with
groups
, I receive this error:why does it expect groups.group_id and not groups.id? I didn't need a event.event_id for events!
Here's the SQL:
The text was updated successfully, but these errors were encountered: