Okay, this release took a bit more to be ready because I'm still recovering from the surgery in the shoulder so I'm working in a diminished speed so I can avoid a new lesion. There's so many improvements and changes that it is hard to describe them in a blog post and don't make it boring to read so I decided to detail only the ones I found more exciting the since others can be found in the changelogs of this release. Right, let's start then...
The purpose of the fading is to isolate certain entities in the canvas area to improve the visualization mainly when handling huge models where the visualization naturally degradates over the time due to the constant objects addition. This feature can be activated via Fade in/out menu item by right clicking the blank portions of canvas area, a set of selected objects or using the same action in the main window's side bar. Note that the options available may vary according to the kind or the amount of objects selected.
There are two special behavior that applies, respectively to tables/views and tags. The first one is when selecting a table or view the subitem Relationships will appear in the fading menu. This action will apply fade factors only to the relationships connected to that table or view. The second behavior can be used to fade in/out only tables and views associated to the selected tag object. To do so just right click the desired tag in the model objects view and choose the available fade options.
The default fade factor is 10% and may vary from 0% to 70%, which can be adjusted in the general settings. Faded objects can be interacted unless the fade factor is 0% which causes objects to be hidden automatically when the fade out effect is applied.
Quick primary key creation
Prior the release 0.9.0-alpha1 the steps to create a primary key were: 1) create the desired columns in the tab Columns; 2) Switch to the tab Constraint; 3) Select the
PRIMARY KEY constraint and then choose the desired columns that would compose the constraint. I'll not enter in technical details of why the constraint creation is that way but I would like to tell that pgModeler tries to replicate the same behaviour as PostgreSQL when handling objects. So, after a long and heated discussion that can be read here and confident of the maturity of pgModeler's codebase I decided that was time to put in practice some of the suggestions deliberated about the subject. Thus, what was done was to automate those 3 steps described before.
Now, after create all desired columns in the table the only thing the user needs to do is to select the ones that will compose the constraint in the section PK. pgModeler will handle the rest creating the primary key object if not present in the table and associate the columns to it. If the table already owns a primary key this object is only updated. It is worthy to mention that pgModeler will generate a name to the constraint and since this is an automatic process it may conflict with other primary key names in the model so it is quite important to validate the model from time to time.
Another important information about this new feature is that the user can't select a column automatically created by a relationship to be a primary key or if the table owns a primary key that was created by a relationship as well. Finally, the classic way to create a primary key is was kept for compatibility purposes.
Improved SQL history
In older releases, the SQL command history was stored in memory during the running session. Once finished the application all the command history was destroyed. Thinking on the situation where sometimes we need to know which commands was executed in a certain moment we have improved the SQL command history as you can see below.
In this new version the SQL command history is persisted in a configuration file called sql-history.conf and kept in the current user's configuration storage. The commands in the history are saved per database connection and register the date/time when they were executed and the results returned as well errors generated. Currently, there is a limit of commands that can be saved in the file and this attribute can be adjusted in the general settings. Once reached its limit the history will automatically destroy the first half of older commands and continue to save any executed SQL. Another improvement included is the context menu in the history which enables the user to reload the history file, save the current history the file, clear all the commands or find keywords in the history.
Another feature brought after some requests is the column duplication. The original request was to make possible the duplication of columns when editing tables. But we gone further, the user can duplicate almost all kind of objects from columns and tables to functions and aggregates. This feature can be used in two different ways: in some editing forms or in the canvas area through the context menu. The first duplication mode is highlighted in the image below. Whenever you find a button in a object's grid with the duplication icon indicates that that kind of object can be duplicated. Just click the button and pgModeler will create an instant copy of it assigning a suffix
_cp to its name indicating that the object was duplicated (or copied).
The second way to duplicate objects in the model is using the context menu and activating the Duplicate action. This is a wider feature compared to the duplication available in editing forms because you can duplicate a single object or a selection of many objects no matter their kind. Note that the duplication operation done in the canvas area works as the regular copy and paste operations but executed once.
Finally, but no less important, we have several miscellaneous improvements that surely will make the design process more pleasant. For instance, you can now use the middle mouse button to move (panning) the model. Also, you can use the arrow keys to move objects. By holding down
Control and using the arrows you'll multiply the moving factor by 10 and holding down
Control + Shift this factor will be increased to 100 allowing longer movements.
In the Manage view we have improved the database explorer widget by adding an special root item to indicate the current working server. But this root item is not there for aesthetical reasons, if you click it certain key server attributes will be exposed (see below). This can be useful, for instance, to troubleshoot third party application problems related to the server configuration parameters.
There are several fixes done in the reverse engineering and diff processes to make them more accurate in addition to other small fixes and changes here and there. The complete set of changes can be found in the file CHANGELOG.md and despite of its length I really recommend a quick reading on it so you can really have an idea on how many effort is devoted to this project to make it even better on each new release.
I'm really grateful to all those who somehow contributed to the growth of this project with suggestions, criticisms or even financial support. I hope you can enjoy this new release because it was made with lots of effort and love! Don't forget to leave your thoughts in the comments.
See you in the next post! ;)