News for hackers. Stuff that matters.

A comment on PostgREST. Parent comment

Re:PostgREST by jdnier on Sunday November 03, 2019 @10:00PM (#21438654)
> You probably would need to adopt a rule of no direct-to-table access, and a separate schema per API version containing views, and dealing with the pain of rewriting the views for all the supported API versions when you need to change your data model.

My understanding is there is no direct-to-table access with PostgREST; you're only ever interacting with views. Keep your view api versions in separate schemas. If you change your tables, yes, you'll need to update your views, but I don't see how that's much different than having to modify ORM code to accommodate schema changes.

[ Parent | on HN ]
Re:PostgREST by Izkata on Monday November 04, 2019 @12:13AM (#21439200)
The examples in these docs start with querying tables, and only afterwards go "oh, it also works with views, if you need more complex filtering".
[ Parent | on HN ]
Re:PostgREST by Doxin on Monday November 04, 2019 @05:06AM (#21440249)
Right, and from my experience the automatic CRUD endpoints don't deal well with views unless you annotate the view with postgrest-specific comments, which seems rather icky to me.
[ Parent | on HN ]
Re:PostgREST by ruslan_talpa on Monday November 04, 2019 @09:42AM (#21442051)
you are confusing postgrest with postgraphile :)
[ Parent | on HN ]
Re:PostgREST by Doxin on Monday November 04, 2019 @10:27AM (#21442474)
Good point. Whoops.
[ Parent | on HN ]
Re:PostgREST by ruslan_talpa on Monday November 04, 2019 @12:53AM (#21439329)
You can’t just throw complexity at ppl from the first lines of documentation especially when talkin about new ideas
[ Parent | on HN ]