Diff Compare model and database the other way

[m-row]

Hi, first i would like to thank you very much for this amazing software, I've been using it for a while and recently tried v1.0.0 beta and i was blown away by the upgrade.

I still have one feature that i thought missing until i read the documentation at: 5.3. Compare model and database

specifically this section:

"The key idea here is that the model is the main reference meaning that any change made to the database that is not in the former is completely ignored. This is useful to keep the model always up-to-date because the user needs to alter first that one and then apply the changes to the database."

my case is the opposite, the database is the main reference and not the model, i do backends so the design is tied to migrations from the application and i import it into pgmodeler to reference or work with. this makes it hard especially if there are many changes i would need to reimport into model and rearrange it visually

[rkhaotix]

Hey @qDisturbance, thank you very much for the feedback about 1.0.0-beta :)

About your situation, yeah I'm aware that some users need to make a diff taking the database as the reference. I discussed this a few times and explained that this is a bit complicated to implement at the moment, but I want to bring this feature in the future.

Anyway, there's a workaround that I developed in order to minimize the annoyance of not having such a feature. The feature in question is the Database model metadata handling. With this feature, you can copy the object's metadata (colors, positions, custom line points, and so on) from one model to another. So, taking your scenario as an example, let's suppose you don't have a database model yet since you work with migrations to design your database. So, the procedure to keep your model always synchronized with your database is doing the following:

1. Make one reverse engineering of your database and save the model somewhere, let's call this file my_db_model_v1.dbm.
2. Adjust the objects' positions, colors, etc in that database model.
3. Keep working on your migrations to incrementally design your database.
4. Once you need a newer model version of your database, make another reverse engineering and save the model with a different name, let's use my_db_model_v2
5. Now, load both my_db_model_v1.dbm and my_db_model_v2.dbm in pgModeler.
6. Make my_db_model_v2.dbm the current visible model and bring the metadata handling to the screen by using the action Fix > Object's metadata on left toolbar.
7. On the metadata handling form, in the field Extract from choose my_db_model_v1.dbm and in Apply to make sure to have my_db_model_v2.
8. Now, you can choose what to extract from model v1 to apply in v2. Once checked the desired options click Apply.

Once the process is finished, you'll see that the objects in model v2 will have the same positions, colors, and other visual attributes as in model v1. You can save my_db_model_v2.dbm and now it'll be your new model. If you need to repeat the process from the beginning, make sure to use v2 as the initial model in step 1.

Again, this is a workaround and I really want to add the definitive feature to make the diff between da database and a model in a more elaborated way. :)

I can help you with this if you have trouble to reproduce the steps above.

[m-row]

Amazing! instructions were pretty clear, worked like a charm 🥳