The objects metadata handling feature, triggered by the icon in the Fix menu at the control toolbar, comes as a workaround for some lacking present in pgModeler. We call metadata all the attributes of objects or even whole objects that aren't converted into SQL code, existing only during design time. Examples of these metadata are tags assigned to tables, textboxes used for general documentation, objects' positioning information, relationships' colors and custom points, generic SQL objects, and some others.

This feature exists due to the following scenario: suppose that you have a fully detailed model with relationships organized by custom points and colors, textboxes being used as small documentation, tables graphically separated by the use of tags, and a set of generic SQL objects which hold some specific code for your database that is being created. Let's then assume that we've exported that model to a PostgreSQL server, so far so good. Now, for some reason, you started to make additions to your database (that one generated from the model), and don't worry about updating the original model. You've created a situation where the model is quite outdated compared to the database. But now you need an updated model of that database so you've to appeal to reverse engineering to get the new model. Of course, the reverse engineering feature is powerful enough to reconstruct the database on its most recent version but all those objects used to make custom documentation and styles of the original model are lost but you need them too. Since pgModeler can't compare a database against a model, updating the latter based on the first, there's no easy way to restore the object's positions, colors, documentation, and tags on the new model. Note that the inverse comparison, model against a database, is completely possible by using the diff feature.

So, this is where the object metadata handling comes to the scene. This feature copies all the metadata of an input model and applies it to another one. In our example, we use the oldest model as input, or to be more clear, from where we'll extract all metadata and apply them to our new database model (the most recent version of the database generated from reverse engineering). Note that the process matches the objects on the involved models by their names so it's recommended to use models that somehow are related, for instance, one being an older version of the other. The whole process can be tweaked by the following dialog.