4 ms·
Great post, thanks for the insight. I have a question regarding this point: > 2. never expose real tables to an application. Create an "API" schema which cont
by rewmie 3y ago
Great post, thanks for the insight.
I have a question regarding this point:
> 2. never expose real tables to an application. Create an "API" schema which contains only views, functions, procedures, and only allow applications to use this schema.
Would a view-based indirection help with rollbacks? For example, in scenarios where a column is added/dropped, would it work to just join with a new relationship column? Rolling back would consist of updating the view to include/exclude the join operation, and the old data would remain in place.
- claytonjy 3y agoYes, this absolutely works. Rather than viewing it as a rollback enabler, I think of it as a way to try things while keeping an escape hatch. Instead of deleting a column from a table, you can remove it from the view, and only drop it from the table when you're really sure that's safe. But dropping a column from the view is an API-breaking change, so rather than updating the existing view I'd make a new view, possibly in a new API schema (e.g. "api_v2"). Then you migrate clients/applications to the new view, and only when nothing uses the old view would I drop both the old view and the column from the underlying table in new migrations.
- spikej 3y agoThis is spot on. I was having this exact discussion last week about how best to "strangle" an older application and deploy the new replacement for an upcoming project.