The objects metadata handling feature, triggered by the icon at the controls 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, relationship colors and custom points, generic SQL objects and some others.

One may ask the reason of this feature to exist and the response could based upon the following: 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 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 not worrying about to update the original model. You've created a situation where the model is quite outdated compared the database. But now you need an updated the model of that database so you've to appeal to the reverse engineering to get the new model. Of course, the reverse engineering 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 first model are lost but you need them too. Since pgModeler can't compare a database against a model, updating the latter based upon the first, there's no easy way to restore the objects positions, colors, documentations, tags, etc on the new model. Note that the inverse comparison, model against a database, is completely possible by the diff feature.

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