After a modest set of changes we've seen the pgModeler 0.9.1-beta I'm really happy to annouce that the last beta of the 0.9.1 has important fixes, changes and cool new features. This release took more time than I was planning due to my lack of time to work on it in the weeks after the launch of the 0.9.1-beta in January, but fortunately I could implement all scheduled features and patches. So let's detail them...
-
The XML construction of domain objects has changed from previous versions of pgModeler in order to support multiple constraints (see below), so if you are using this kind of objects in your model be sure to run the model fix tool via CLI or let pgModeler provide the fix automatically when opening the the model file. In any case it is recommended to have a backup of your database model file in order to avoid file corruption in rare circumstances.
-
macOS users: it is almost certain that pgModeler will not find the configurations folder created by the previous versions. By default, the settings were stored under /Users/[user]/Library/Preferences/br.com.pgmodeler since the folder has changed in this new release so you'll need to copy the files in the mentioned path to the new one located at /Users/[user]/Library/Preferences/io.pgmodeler
** Multiple relationships for the same tables **
After many requests I decided to change the way which the relationships are created and now pgModeler allows multiples relationships for the same pair of tables. In previous versions, pgModeler would refuse to create a second relationship between the tables A and B. From now on, pgModeler will accept the creation of one-to-many and many-to-many relationships connecting A and B more than once. For the other kinds of relationships (generalization, copy, one-to-one) the old rule is still valid: only one relationship per table pair is accepted.
** Row level security (RLS): better late than never **
Introduced still in PostgreSQL 9.5 the row level security is an extension to the SQL-standard privilege system in which tables can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands. Unfortunately I couldn't implement this feature in pgModeler on the time it was officially released, but now, our tool have it fully supported in two parts. The first one is the options ENABLE RLS and FORCE RLS in the table editing form which causes tables to have RLS enabled and/or forced according to the official docs . The second part of RLS support was the introduction of the policy object which dictates how data must be read or written and by who, see details here. It's important to note that the reverse engineering and diff processes are prepared to import policies as well generated diff code for this new feature, respectively.
** Identity columns for the win **
The identity columns, introduced in PostgreSQL 10, are a really cool feature brought to us and I really like them. Actually, the PostgreSQL implementation of identity columns works pretty much as the old but good sequences for auto incremented columns but with some important improvements which can be seen here and here. Indentity columns are configured in the column editing form as highlighted in the following image.
** Extensions and domains in the right way **
An old missinterpretation of the PostgreSQL's documentations was fixed in this release by changing the way extensions are stored in the database model. Previously, this kind of object was stored at schemas level but the right way to store them is at database level. So now instead of seeing extensions in the schema's subtree you'll see them in the database subtree.
Another wrong implementation in pgModeler is fixed and was related to domains. According to docs these objects can have multiple check constraints but prior this version pgModeler was accepting only one. Now, you're free to create as many as needed check constraint in domains.
All validation rules, export, import and diff processes were fixed in such way to reflect the right way to treat these objects.
** Miscellaneous fixes and changes **
An important change, and that one is related to an annoying behaviour of the tool, is that pgModeler will silently ignore the absence of the plugins folder and proceed with the normal startup avoiding the display of a message box regarding the missing folder and automatically disabling the plugins search mechanism.
About the fixes, a patch was done in order fix a bug that was causing recurrent crashes on macOS when the user tried to load a second model file making almost impossible the working on two or more database models at once. Also, the reverse engineering was patched in such way to avoid the duplication of data types related to tables, sequences and views which was causing problems during the validation process. Another fix was done in the diff process that was generating a malformed DROP command for extensions.
Well, not all changes are described here so I really recommend that you take a look into the complete change log for the full set of improvements brought in this release.
Finally, I'm happy to announce that pgModeler will be on an official PostgreSQL event for the first time. The PGConf.Brasil is one of the most important events related to PostgreSQL happening in Brazil and I'll be there in flesh to talk a little bit about my project.
That's it! Remember that all communication channels are open to suggestions or criticisms. Enjoy this new pgModeler!
See you next time.
Add new comment