Modelling versioning in Postgres
От | Laura Smith |
---|---|
Тема | Modelling versioning in Postgres |
Дата | |
Msg-id | SnkMvVFCIfgaohLICjYwKEwe1LsI3EUX1XzYACFL8gNyBiCqUqrOKi6xu2rrDirSesUBuC45sPxWgAaVx6z_nZuBCNx_pQUcpR1dvftab8s=@protonmail.ch обсуждение исходный текст |
Ответы |
Re: Modelling versioning in Postgres
|
Список | pgsql-general |
Hi I was wondering what the current thinking is on ways to model versioning in Postgres. The overall premise is that the latest version is the current version unless a rollback has occurred, in which case versionsget tracked from the rollback point (forking ?). My initial naïve starting point is something along the lines of : create table objects ( objectID uuid, versionID uuid, versionTS timestamp objectData text ); This obviously creates a fool-proof answer to "latest version is the current version" because its a simple case of an "whereobjectID=x order by versionTS desc limit 1" query. However it clearly doesn't cover the rollback to prior scenarios. I then though about adding a simple "versionActive boolean". But the problem with that is it needs hand-holding somewhere because there can only be one active version and so it wouldintroduce the need for a "active switch" script somewhere that activated the desired version and deactivated the others. It also perhaps is not the right way to deal with tracking of changes post-rollback. How have others approached the problem ? N.B. If it makes any difference, I'm dealing with a 12.5 install here, but this could easily be pushed up to 13 if thereare benefits. Thanks for your time. Laura
В списке pgsql-general по дате отправления: