You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Say we had a schema, the_data with three tables, a, b, and c. We have some users that have read/write access to all the tables in the_data, but after a while we decide that we do not like table b so we'd like to deprecate it by first restricting access to it for a while and then dropping the table properly later.
I'm open to other suggestions like "how about you just move table b to an off-limits schema", but I wanted to discuss if this is a pattern that's useful and if so what would that look like in the spec def?
The text was updated successfully, but these errors were encountered:
ohh that's a good call. then we don't have to check weird interactions, we can just mark stuff to be ignored and manually manage it out of band from the spec.
Say we had a schema,
the_data
with three tables,a
,b
, andc
. We have some users that have read/write access to all the tables inthe_data
, but after a while we decide that we do not like tableb
so we'd like to deprecate it by first restricting access to it for a while and then dropping the table properly later.I'm open to other suggestions like "how about you just move table
b
to an off-limits schema", but I wanted to discuss if this is a pattern that's useful and if so what would that look like in the spec def?The text was updated successfully, but these errors were encountered: