The main goal of this tool is to avoid references or rules breaking during design time, as well as to prevent problems when exporting the model directly to a PostgreSQL server. This mechanism simplifies the way pgModeler loads and saves the model files, shortening the execution time of these two operations with the advantage that the validation creates a consistent, reliable, and error-free model. The validation process is divided into six steps: reference checking, name uniqueness checking, permanent relationship invalidation checking, missing PostGiS extension, unique keys similar to primary keys, and object's SQL checking.

The first validation, reference checking, will analyze if the objects are being created in the correct order. The basic rule when designing in pgModeler is that all objects must be created in a certain chronological order, but in many cases, the user cannot predict this situation and make links between objects without worrying about their creation order. This can generate a database model with several reference breaks, which means, objects being created before their dependencies.

In the second validation step, the name uniqueness checking, pgModeler verifies if tables, views, primary keys, unique keys, and exclude constraints have distinguished names if they reside on the same schema.

Now, the permanent relationship invalidation checking will look for the relationships that are permanently broken. A broken relationship in this context is the one that has the column propagation affected in some way, so one or more columns aren't created from the reference table to the receiver one (details about the column propagation mechanism can be found in section Relationships at Chapter 3. The only solution for permanent invalidation is the relocation of the relationship, which means changing the creation order of the object.

The missing PostGiS extension validation step checks if one or more columns in the tables use spatial data types provided by the PostGiS extension, raising errors in positive cases and proposing the solution for the problem, which is, create the extension in the database model.

Another validation step is the unique keys similar to primary keys checking. In this step, pgModeler checks if the primary key and unique key constraints in the same table have the same columns. Although this is completely possible in PostgreSQL, pgModeler will warn the user about the situation. This is done because, if the user tries to export the model with this situation unresolved, PostgreSQL will completely ignore the unique keys having the same configuration as the primary key in their parent table, which can cause certain confusion to the user.

The object's SQL checking is the last validation step, and it is useful to verify other details on the generated SQL, like stored procedures syntax, views definitions, and many other aspects not covered by the first five validation steps. An important note here is that this process will not be executed while the model does not pass the previous validation iterations.

Despite being possible to save an invalidated model, this is a risky and not recommended action since it can produce a corrupted model file that will demand fixes through the model fix tool or the command-line interface, so to avoid problems, always validate your model before saving it. The validation widget on the image below encapsulates all the validation steps in a single object. The process is quite verbose, which facilitates the identification of errors. After executing the validation process, you can manually fix the problem based on the errors returned or let pgModeler apply automatic fixes for you.