The DTD (document type definition) structure of the database model file has changed since the last stable 0.9.2. Models created in older releases will certainly fail to load due to incompatibilities because some attributes in the XML code does not exist anymore or have changed during the development of 0.9.3. Before loading your database models in this new release, please, make sure to have a backup of all them and follow the steps presented by the model fix tool to correct the documents' structure. Not paying attention to this situation may cause irreversible data loss! If the fix procedures aren't enough to make your database model loadable again, please, ask for help at the official support channels!
The year 2020 will mark every person globally due to all problems we have faced and still facing. Many lives lost, economic problems worldwide, and a crazy race in searching for a vaccine for COVID-19. Fortunately, things are starting to stay in place again, and I hope we can get back to our normal lives very soon.
This year was particularly complicated and distressful for me because I had some health problems that critically affected the development of 0.9.3, causing some release delays. Since I always had quality in mind, I preferred to delay a launch and polish the software a bit more instead of releasing a half-baked product. I know I promised a six-month cycle, but unfortunately, the entire development of 0.9.3, from alpha to stable, took one year due to the circumstances already mentioned. I didn't expect such a challenging moment.
Recap of features introduced by alpha and beta stages
The 0.9.3 brought important improvements to pgModeler in this development cycle. In its first alpha release pgModeler introduced the objects multi selection which allows applying actions to the set of objects selected in the results grid on object finder widget, or the model objects tree. This was a big step since it can speed up the design process in several ways. Another improvement in 0.9.3-alpha was the multiple objects renaming, which allows one to apply the renaming action to the current object selection.
Still in the first alpha, another important new feature was added, initially by a third party contribution but improved later, which is the ability to move up and down the objects in the Z coordinate, also know as Z stacking, in the design view. This feature allows the user to keep in the front all the meaningful objects and place those less important at the back of the view. The Z coordinate manipulation is a persistent change, which means changing objects stacking will be saved to the database model file and restored whenever the model is loaded.
The quick results sorting in data manipulation form was also introduced by 0.9.3-alpha and allowed the user to sort the results displayed in that form quickly without the need to use the
Order & Limit field. Basically, if you click the column name on the top of the results grid, a new
SELECT ... FROM query will be performed by attaching the
ORDER BY [column] ASC|DESC in the internal query used to retrieve the data to be displayed.
Now, pgModeler 0.9.3-alpha1 kept the cycle of enhancements delivering important changes. The first one I would like to highlight is the ability to manage relationship-generated objects which basically allows the user to change the attributes of any column or constraint automatically created through a relationship between two tables. Still in this line, that release introduced an improved semantics for relationships created from foreign keys added manually by the user (known as FK relationships). Now, pgModeler tries to guess the correct semantics of an FK relationship and renders it as one-to-one or one-to-many depending on how the columns, not null, foreign key, and unique key constraints are configured.
The reverse engineering filters was another functionality introduced by alpha1 with productivity in mind. The user can now provide filtering patterns that force pgModeler to list only those items matching the defined criteria. This is really useful when you need to import just a small set in a huge database. This feature opened the possibility to create the partial diff feature introduced later by 0.9.3-beta.
pgModeler 0.9.3-beta introduced the database model changelog, which registers any modification performed over the database model and when they happened. Also, in this release, the partial diff feature was introduced and consists of taking an input database or model, apply user-provided filters diminishing the number of objects to be compared, bringing us a significant gain of speed in the whole comparison process because only a subset of the database/model will be handled.
In pgModeler 0.9.3-beta1 all the planned features were implemented, and it was time only to polish them. Some minor features were introduced here and there too.
Finally, after 4 development releases, we have reached the long-awaited stable release, which brings some small improvements to be detailed in the next sections.
Improved collation objects
[Collation objects]((https://www.postgresql.org/docs/13/sql-createcollation.html) were improved in such a way to allow the use of the attributes
deterministic (PostgreSQL 12+) and
provider (PostgreSQL 10+). A deterministic collation uses deterministic comparisons, which consider strings that are not byte-wise equal to be unequal even if they are considered logically equal by the comparison. The provider attribute specifies the provider to use for locale services associated with a collation, like
Bulk relationships selection
Like some of the other releases of 0.9.3, this stable one improved the object selection. This time, specifically, the relationships selection. Now, it's possible to select all relationships connected to a table at once without the need to manually selecting each one. This is very useful if you need to quickly perform certain operations over all the relationships. These operations can be move to a specific layer, fade in/out, copy, delete, etc. To trigger the bulk selection of relationships, right-click a table and activate
Select relationships and all relationships will be marked as selected at the same time the table itself is deselected.
New search fields in object finder widget
Maybe you may not know, but pgModeler allows searching objects by matching different attributes since 0.9.2-beta. This feature in 0.9.3 received a small improvement. It now allows one to search relationships by the involved table names (source and destination table), constraints by their column names (source and referenced columns), and relationships by the foreign key names related to them.
This release adds missing check constraints to the data dictionary files. Also, it fixes a bug in the data dictionary generation that was preventing default values of columns tied to sequences to be correctly displayed.
The fade in/out action for tables, views, and foreign tables was improved. Now it's possible to fade only the relationships linked to those objects, the peer tables linked to the selected table via relationships, or even both object kinds. To trigger the fade in/out action, the user must right-click a table (view or foreign table) and focus
Fade in/out. Once highlighted the fade action, the options
Fade in (out),
Peer tables and
Both are displayed.
This version brings fixes to different parts of the software. pgModeler will not quit unexpectedly when selecting children objects of a schema that has no rectangle defined. Also, a proper patch was applied, and a crash during the importing of domain objects will not happen anymore. The reverse engineering of objects into the currently loaded model will not break the application too. In particular cases, that bug was happening when the model had some tables or views referencing columns added by relationship.
The command-line interface was a bit broken in 0.9.3-beta1, and some options weren't being accepted by the program even if they were valid. All the options were revised and validated, and now the CLI is accepting them as expected. A bug that was causing infinite validation of imported sequences is occurring no more. This could cause the database model's corruption, making it never loadable since the whole structure was not validated and the objects not in the correct creation order.
The complete list of changes of this release is available in the file CHANGELOG.md. Please, don't forget to let your feedback in the comments section or at GitHub! Help me to improve pgModeler in such a way to transform it into a reference at the PostgreSQL community! :)
Well, that's it! Enough of pgModeler this year. There's only one pending task right now: updating the documentation with all features changed or introduced by 0.9.3, but I'll let it to the beginning of 2021 since I really need a bit of rest and to take care of my health. Anyway, with this launching, I'm starting to plan my next moves regarding the future of this project. Maybe we'll have another 0.9.x series or maybe we'll move to pgModeler 1.0... I still don't know for sure, but the 1.0 is likely to happen anytime soon. ;)
Lastly, I would like to thank the whole community around pgModeler for each suggestion and criticism all these years. It may not be the biggest community, but it is the one I could gather around a dream I had for too long and now is a reality. This project is very important for me and each person that contributes to it, no matter the way, has my eternal gratitude!
I wish you a wonderful new year with plenty of realizations!
Happy 2021! ;)