Continuing our love story with PostgreSQL and QGIS, we asked QGIS.org a grant application during early 2017 spring.
The idea was to take benefit of very advanced PostgreSQL features, that probably never were used in a Desktop GIS client before.
Today, let’s see what we can do with the PostgreSQL NOTIFY feature!
Ever dreamt of being able to trigger things from outside QGIS? Ever wanted a magic stick to trigger actions in some clients from a database action?
NOTIFY is a PostgreSQL specific feature allowing to generate notifications on a channel and optionally send a message — a payload in PG’s dialect .
In short, from within a transaction, we can raise a signal in a PostgreSQL queue and listen to it from a client.
In action
We hardcoded a channel named « qgis » and made QGIS able to LISTEN to NOTIFY events and transform them into Qt’s signals. The signals are connected to layer refresh when you switch on this rendering option.
Optionnally, adding a message filter will only redraw the layer for some specific events.
This mechanism is really versatile and we now can imagine many possibilities, maybe like trigger a notification message to your users from the database, interact with plugins, or even code a chat between users of the same database (ok, this is stupid) !
More than just refresh layers?
The first implementation we chose was to trigger a layer refresh because we believe this is a good way for users to discover this new feature.
But QGIS rocks hey, doing crazy things for limited uses is not the way.
Thanks to feedback on the Pull Request, we added the possibility to trigger layer actions on notification.
That should be pretty versatile since you can do almost anything with those actions now.
Caveats
QGIS will open a permanent connection to PostgreSQL to watch the notify signals. Please keep that in mind if you have several clients and a limited number of connections.
Notify signals are only transmitted with the transaction, so when the COMMIT is raised. So be aware that this might not help you if users are inside an edit session.
QGIS has a lot of different caches, for attribute table for instance. We currently have no specific way to invalidate a specific cache, and then order QGIS to refresh it’s attribute table.
There is no way in PG to list all channels of a database session, that’s why we couldn’t propose a combobox list of available signals in the renderer option dialog. Anyway, to avoid too many issues, we decided to hardcode the channel name in QGIS with the name « qgis ». If this is somehow not enough for your needs, please contact us!
Conclusion
The github pull request is here : https://github.com/qgis/QGIS/pull/5179
We are convinced this would be really useful for real time application, let us know if that makes some bells ring on your side!
More to come soon, stay tuned!
Awesome stuff, this will bring integrated applications to a whole new level. Thanks for making this longstanding idea come true!
Interesting, what about starting a server on QGIS in the same way JOSM remote control works and then make a call using Paul Ramsey’s http client?
https://github.com/pramsey/pgsql-http
Making http calls from within a database, mixing systems with very different latencies, does not sound like a really good idea in terms of infrastructure robustness.
Using messages queues are done for this specific kind of use cases.
And thanks for the original idea!
How does one actually use this then? What does need to be set in QGIS and when? What needs to be done on the PG side and when?