Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lLDY5-0002ux-99 for pgsql-novice@arkaria.postgresql.org; Sat, 13 Mar 2021 23:19:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lLDY2-000496-Fz for pgsql-novice@arkaria.postgresql.org; Sat, 13 Mar 2021 23:19:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lLDY2-00045S-6v for pgsql-novice@lists.postgresql.org; Sat, 13 Mar 2021 23:19:54 +0000 Received: from mail-il1-x135.google.com ([2607:f8b0:4864:20::135]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lLDXz-00073E-H9 for pgsql-novice@lists.postgresql.org; Sat, 13 Mar 2021 23:19:52 +0000 Received: by mail-il1-x135.google.com with SMTP id h18so6062352ils.2 for ; Sat, 13 Mar 2021 15:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2arO9pkBz2IPfcyFHOEZ9bwQ4R9fMUHNWPQ9Bh5H+0U=; b=fHUH+Jw2athd63xUs2ae3d4slqMsgW8EQTK0aSqfuzAeIbgzUvgfQHTMEedNftUFFi yZIyU4zpv3GGHE9DrmZDPevDMGGhxgmiTTAMQlKTBG0W3ZdI0ZYsw+vxH1g10KvZfM57 Jo/j8Ve7J+YyDz9OFf8M0BCXwaOeXbe8Czl7DOkzWjRt71MH6m5KwuHTrGAsqXvNW7/P noZy0/xzHF6L4plyqOzUTMGmW95QB3hF5D+WNj3FoVx1EU915mE2EnCbVgWp+ctwzjyt RPqbpvwZbM9jO1fYZ5X4Gw09yQxI85zCDYIkw0Xqm8OqKHh28p/JzxLZQkVN6HaRrKEN R9Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2arO9pkBz2IPfcyFHOEZ9bwQ4R9fMUHNWPQ9Bh5H+0U=; b=mpZfiz3g4FaItgtI8YK+mSgCEytj2tJKAfFu4os1RdCIZDpDlfxBy+KTLGXwokmMlW xuYajrGX+v/L+tSkqjvOUlyV9UDGGVDohzEyLLZo8lwP0XJNSlEGUUqdWlauhPbsLJ7+ rewyGhFmxus/J45UWF+1PYbIhZtJ5urGQvIo0yXHZ6xx38MXI0RCPCcYcOOTqj43BFtT QNJ3omDEVBxjEwqtlR1ixu0BYYkJQerZPKL89Xj3elkeNhE7XkzJPu6Z6G/FYaX6KV2w ebZEbh/yUos0kIz9FewdoSbo0nwUheat99BmDPDSWcXqwdWtQwrnSMdi0/U5o/tJ7rVE iGXA== X-Gm-Message-State: AOAM5328vvomWsMKXYwbzW+p6QgtH3BnW7EbvNLqyJUcuGkfCfG8ZEsr UJWfoxuiczEmRLnF5P4znuA8q/xfHwaOcaAF2aE= X-Google-Smtp-Source: ABdhPJz5ZpSGds3JY6QXW2ByhdX3idwwnQyfsK+Jc0GR9akp4CBndtX5KzZc91Swl5GNYG78/uXPgqECDb1LvoUl2yo= X-Received: by 2002:a05:6e02:1c2a:: with SMTP id m10mr7242814ilh.104.1615677590541; Sat, 13 Mar 2021 15:19:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steve Baldwin Date: Sun, 14 Mar 2021 10:19:35 +1100 Message-ID: Subject: Re: Database migrations To: Simon Connah Cc: "pgsql-novice@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000db1a1905bd734057" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000db1a1905bd734057 Content-Type: text/plain; charset="UTF-8" Hi Simon, Another option (and the one we use) is a tool called flyway - https://flywaydb.org/. There is a free community edition, and it is pretty comprehensive. There are docker images you can use during ci. Flyway supports versioned (run once) migrations, repeatable (run when changed) migrations, and a bunch more. Other than being a user of the community edition, I have no association with flyway. Cheers, Steve On Sun, Mar 14, 2021 at 8:40 AM Simon Connah wrote: > Hi, > > I'm sorry if this is a rather stupid question but I'm fairly new to > databases and was wondering if anyone could offer some advice? > > I have an app I am developing using Node.js and PostgreSQL 13.2. I have > the basic tables I want to start with but I know that as development > progresses change is going to be required. Since this is an open-source > project people are going to want to upgrade from one version to the next > and that might require changes to the database structure. What is the best > way to handle this? > > I was thinking about just having a bunch of SQL files with a version > number and date and applying them to the database from oldest to newest > (with a table storing information for files that have already been > processed). Does this sound like a reasonable solution? > > If not could someone point me in the right direction, please? > > Thank you for your help. > > Simon. > > > > > --000000000000db1a1905bd734057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Simon,

Another option (and the= one we use) is a tool called flyway -=C2=A0https://flywaydb.org/. There is a free community edition, and it is = pretty comprehensive. There are docker images you can use during ci.
Flyway supports versioned (run once) migrations, repeatable (r= un when changed) migrations, and a bunch more.

Oth= er than being a user of the community edition, I have no association with f= lyway.

Cheers,

Steve

On Sun, Mar 14, 2021 at 8:40 AM Simon Connah <simon.n.connah@protonmail.com> wrote:
Hi,

I'm sorry if this is a rather stupid question but I'm fairly new to= databases and was wondering if anyone could offer some advice?

I have an app I am developing using Node.js and PostgreSQL 13.2. I have the= basic tables I want to start with but I know that as development progresse= s change is going to be required. Since this is an open-source project peop= le are going to want to upgrade from one version to the next and that might= require changes to the database structure. What is the best way to handle = this?

I was thinking about just having a bunch of SQL files with a version number= and date and applying them to the database from oldest to newest (with a t= able storing information for files that have already been processed). Does = this sound like a reasonable solution?

If not could someone point me in the right direction, please?

Thank you for your help.

Simon.




--000000000000db1a1905bd734057--