search

michaelsogos / pg-diff

PostgreSQL schema and data comparing tool
MIT License
171 stars 17 forks source link

Question: Rollback to a certain version on a same system #33

Closed ivanDespot closed 3 years ago

ivanDespot commented 3 years ago

Hello Michaelsogos.

I started using pg-diff, and it works like a charm.

Could you just tell me if it's possible to revert to a certain version on a source system. Target system aside for now, let's consider the following case. I am developing my data model, adding some functions and saving it to migration table - V1. Then I add some other db stuff and save it again - V2. Next I start working on some new feature and create V3. What if I realize that this feature is not needed or I just didn't implement it correctly, is there some convenient way to revert back to V2 or V1? To summarize, I would like to track my development progress on the source system and revert to a certain version if needed. For example: Compare V2 and V3 and rollback all changes made during V2 >> V3 migration

Best regards, Ivan

michaelsogos commented 3 years ago

Dear @ivanDespot

Thanks for using my tool. The answer is no.

When I started developing pg-diff I was coming from years using other tools, and all of them implemented classical migration strategy based on Up() and Down() functions.

I don't agree totally with rollback strategy bacause essentially it cannot work in every case and is very dangerous. From my experience, I never needed to deploy a sql patch that wasn't well tested; this works for me because I know what I did in develop machine and tested again in develop machine before commit my changes.

That's why I choose to not include a rollback strategy, but hey! You can still make a new following patch to revert back changes.

Let me try to explain a possible way to work. Image that you develop a software based on pgsql. You should have two databases, one to make changes and very important never connected with software; another one to compare with the above db, make patch, try to apply that patch and connected with your software. As soon as possible you start debugging or whatelse in order to check your changes. If changes are OK than you can commit sql patches on source code repository and then share it with your team in case, else delete created patch from your workspace.

In case you use this tool just for databases as diff tool, then you should not apply patch if unsure, but in any case try an approach "fast-forward" always, that in other terms means you should create a new patch to revert back changes.

Make it sense for you?