Re: Advice request : simultaneous function/data updates on many databases

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Advice request : simultaneous function/data updates on many databases
Date: 2020-03-04 22:30:48
Message-ID: CAKFQuwZG=d5SgEwbFa2o84mgM-wAUrnoJJrZaX+TF-zJG9zMNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Mar 4, 2020 at 3:04 PM Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
wrote:

> However, for larger updates, the time when the front end code is
> out-of-step with the database can cause end-user problems.
>

You should try very hard to structure your database migrations so that
instead of going directly from uniquely valid state to another uniquely
valid state you instead transition to a dual-ly valid state (i.e., don't
break the old way of doing things while adding the pieces to make the new
way of doing things work) and then separately remove the old valid state
components once you know all of the software upgrades have been deployed.

Add New Stuff, Leave Old Stuff Alone
Remove Old Stuff

Triggers can be installed during the transition period to facilitate the
duplication of data that will result.

This should be considerably easier for non-data impacting updates as you
can just choose different names for the new stuff then remove the old stuff
separately.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rory Campbell-Lange 2020-03-04 22:33:42 Re: Advice request : simultaneous function/data updates on many databases
Previous Message Adrian Klaver 2020-03-04 22:27:41 Re: Advice request : simultaneous function/data updates on many databases