3 ms·
> 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 rew
by jdnier 7y ago
> 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.
- Izkata 7y agoThe examples in these docs start with querying tables, and only afterwards go "oh, it also works with views, if you need more complex filtering".
- ruslan_talpa 7y agoYou can’t just throw complexity at ppl from the first lines of documentation especially when talkin about new ideas
- Doxin 7y agoRight, 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.
- ruslan_talpa 7y agoyou are confusing postgrest with postgraphile :)
- Doxin 7y agoGood point. Whoops.