exekias

5 ms·

1.
by exekias 3y ago
I don't know much about Liquidbase, but I believe it doesn't support accessing both the old and the new schema versions at the same time? (I could be wrong here) Backfilling happens in batches, we use the PK of the table to update
2.
by exekias 3y ago
To do this with pgroll I would use an alter_column migration, changing the type: https://github.com/xataio/pgroll/tree/main/docs#change-type , this would: 1) Create a new column with the desired type (num
3.
by exekias 3y ago
Yes, this is the case as of today. It's important to get the up/down functions right. The good thing is that this will probably be detected during the start phase, as data would fail to be backfilled. We are thinking of ideas to i
4.
by exekias 3y ago
This is a good point, I believe we can look into trying to estimate storage needs or timings before a migration. It definitely looks like a nice to have.
5.
by exekias 3y ago
For migrations altering columns (for instance adding a constraint), data gets upgraded/downgraded between old and new versions trough the up/down functions. These are defined by the migration. They work like this: - For rows inser
6.
by exekias 3y ago
Thanks for reporting! we will look into it
7.
by exekias 3y ago
^ this is exactly how it works :)
8.
by exekias 3y ago
That is what this project is trying to achieve. By allowing your client apps to access both the old and the new schema at the same time, you can have the old instances of your application working while the new ones (using the new schema) ge
9.
by exekias 3y ago
This is actually the case, old and new schemas are available and working until you complete the migration, and you can run this step whenever you want. The aim is not to deal with conditional logic in the app dealing with both schemas, but
10.
by exekias 3y ago
I didn't fully understand the change that you are explaining, but in general having old & new schemas working relies on the migration definition having the proper `up` & `down` functions defined. These are postgres functions so
11.
by exekias 3y ago
We use a few statements that are not supported by previous versions. For instance `CREATE OR REPLACE TRIGGER`. Supporting previous versions would be possible, but we went for the most recent ones to reduce complexity.
12.
by exekias 3y ago
Hi, one of the authors here! The tool is open source and doesn't require any subscription :)
13.
by exekias 3y ago
I believe this is one of the reasons why migrations become scary in many cases. If something goes wrong "the only path is forward". Also, rolling out new versions of the application means either breaking the previous versions (wit
14.
by exekias 3y ago
Thank you for noticing this! We are looking into changing the wording :)
15.
by exekias 3y ago
Hi there, I'm one of the pgroll authors :) I could be mistaken here, but I believe that pg-osc and pgroll use similar approaches to ensuring no locking or how backfilling happens. While pg-osc uses a shadow table and switches to it at
16.
by exekias 3y ago
> This looks very nice indeed but I see a few possible problems which I have seen with pg_repack which might apply to this approach as well: Thank you for your input! I'm one of the pgroll authors :) > You can't change table
17.
Host Your Own Data with Docker, Owncloud, Caddy and Let's Encrypt(exekias.me)
4 points by exekias 11y ago|0 comments