Open dvv opened 10 months ago
As a rule we try to keep pg_graphql as configuration-free as possible
For excluding entities from insert/update/delete the best solution is to revoke insert
/update
/delete
access from the relevant role.
I could see an argument for a comment directive to exclude it from the Query
object though and it wouldn't be very invasive.
Will leave this open and mark as good first issue
Well, revoking access does disable operations at db low-level as well. One has no option to disable access via graphql layer only, nope?
Being able to exclude tables from the schema is a logical feature, IMO. As @dvv mentioned, it isn't really feasible to restrict permissions on a table to the point where we can't interact with it.
My current use case that ties into this is that I need to extend my schema in a way that pg_graphql does not currently support.
To achieve this, I'm writing a small microservice with an edge function and stitching the endpoints together.
It would be nice to exclude the relevant tables from the pg_graphql schema so that I can expose them through this microservice as a modular unit.
I can, of course, handle type dupes and such in the stitching, but that creates more work than needed if I could simply decorate the table in Postgres to tell pg_graphql not to include it in the schema.
In my case, I would like the user to be able to create entities and see the entity id
field. However, I do not want users to be able to pick their own id
s during creation/update. This would be much more explicit if I could remove the id
field from the mutation type only.
@FelixZY for an id
fields you can accomplish this by making that value a serial
type or generated
in both of those cases the API excludes those fields from each table's insert and update types so your value is always generated by postgres rather than being provided by the user
I'll open an issue to add that info to the docs
Please consider adding an
internal
(exclude
?) directive for any sort of fields. This should move the field out of Query/Mutation while keeping it available on deeper levels.The default to be the scope's value.
This is mainly to housekeep the Query/Mutation clean while having all needed things in one exposed db schema.