Re: DDL Damage Assessment

* Harold Giménez (harold(at)heroku(dot)com) wrote:
> I think the main issue is when a table rewrite is triggered on a DDL
> command on a large table, as this is what frequently leads to
> unavailability. The idea of introducing a NOREWRITE keyword to DDL
> commands then came up (credit: Peter Geoghegan). When the NOREWRITE
> keyword is used and the DDL statement would rewrite the table, the
> command errors and exits.
>
> This would allow ORM and framework authors to include the NOREWRITE
> option by default, only to be disabled on a per-statement basis by the
> developer, once they have assessed that it may be safe or otherwise
> they still want to proceed with this. The workflow for an app
> developer then becomes:
>
> * Write offending data migration (eg: add a column with a NOT NULL
> constraint and default value)
> * Test it locally, either by running automated test suite or running on staging
> * See that it fails because of NOREWRITE option
> * Assess situation. If it's a small table, or I still want to ignore,
> override the option. Or rewrite migration to avoid rewrite.
> * Repeat
>
> I like this a lot just because it's simple, limited in scope, and can
> be easily integrated into ORMs saving users hours of downtime and
> frustration.
>
> Thoughts?

Not against it, but feels like an independent thing to consider- what
Devrim is suggesting is broader and encompasses the issue of locks,
which are certainly important to consider also.

In short, seems like having both would be worthwhile.

Thanks,

Stephen