QGIS/python/core/auto_generated/qgsdataprovider.sip.in

452 lines
12 KiB
Plaintext
Raw Normal View History

2017-04-27 22:56:55 +02:00
/************************************************************************
* This file has been generated automatically from *
* *
* src/core/qgsdataprovider.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/
class QgsDataProvider : QObject
{
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Abstract base class for spatial data provider implementations.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
This object needs to inherit from QObject to enable event
processing in the Postgres/PostGIS provider (QgsPostgresProvider).
It is called *here* so that this vtable and the vtable for
QgsPostgresProvider don't get misaligned -
the QgsVectorLayer class factory (which refers
to generic QgsVectorDataProvider's) depends on it.
2017-04-27 22:56:55 +02:00
%End
%TypeHeaderCode
2017-04-27 22:56:55 +02:00
#include "qgsdataprovider.h"
%End
%ConvertToSubClassCode
2017-04-27 22:56:55 +02:00
if ( qobject_cast<QgsVectorDataProvider *>( sipCpp ) )
{
2017-04-27 22:56:55 +02:00
sipType = sipType_QgsVectorDataProvider;
}
2017-04-27 22:56:55 +02:00
else if ( qobject_cast<QgsRasterDataProvider *>( sipCpp ) )
{
2017-04-27 22:56:55 +02:00
sipType = sipType_QgsRasterDataProvider;
}
else if ( qobject_cast<QgsMeshDataProvider *>( sipCpp ) )
{
sipType = sipType_QgsMeshDataProvider;
}
else
{
2017-04-27 22:56:55 +02:00
sipType = 0;
}
%End
public:
enum DataCapability
{
NoDataCapabilities,
File,
Dir,
Database,
Net
};
enum ProviderProperty
{
2017-04-27 22:56:55 +02:00
EvaluateDefaultValues,
CustomData
};
struct ProviderOptions
{
2018-05-27 17:52:22 +02:00
int unused; //! @todo remove me once there are actual members here (breaks SIP <4.19)
};
2018-05-21 11:13:05 +10:00
QgsDataProvider( const QString &uri = QString(), const QgsDataProvider::ProviderOptions &options = QgsDataProvider::ProviderOptions() );
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Create a new dataprovider with the specified in the ``uri``.
Additional creation options are specified within the ``options`` value.
2017-04-27 22:56:55 +02:00
%End
virtual QgsCoordinateReferenceSystem crs() const = 0;
%Docstring
2017-12-15 10:36:55 -04:00
Returns the coordinate system for the data source.
If the provider isn't capable of returning its projection then an invalid
QgsCoordinateReferenceSystem will be returned.
2017-04-27 22:56:55 +02:00
%End
2017-04-27 22:56:55 +02:00
virtual void setDataSourceUri( const QString &uri );
%Docstring
2017-12-15 10:36:55 -04:00
Set the data source specification. This may be a path or database
connection string
2017-12-15 21:36:08 -04:00
2017-12-15 10:36:55 -04:00
:param uri: source specification
2017-04-27 22:56:55 +02:00
%End
2017-04-27 22:56:55 +02:00
virtual QString dataSourceUri( bool expandAuthConfig = false ) const;
%Docstring
Gets the data source specification. This may be a path or database
2017-12-15 10:36:55 -04:00
connection string
2017-12-15 21:36:08 -04:00
2017-12-15 10:36:55 -04:00
:param expandAuthConfig: Whether to expand any assigned authentication configuration
:return: data source specification
2017-04-27 22:56:55 +02:00
.. note::
The default authentication configuration expansion is FALSE. This keeps credentials
2018-01-12 20:51:17 -04:00
out of layer data source URIs and project files. Expansion should be specifically done
only when needed within a provider
2017-04-27 22:56:55 +02:00
%End
void setUri( const QgsDataSourceUri &uri );
%Docstring
2017-12-15 10:36:55 -04:00
Set the data source specification.
2017-04-27 22:56:55 +02:00
.. versionadded:: 3.0
%End
QgsDataSourceUri uri() const;
%Docstring
Gets the data source specification.
2017-12-15 10:36:55 -04:00
2017-04-27 22:56:55 +02:00
.. versionadded:: 3.0
%End
virtual QgsRectangle extent() const = 0;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Returns the extent of the layer
:return: QgsRectangle containing the extent of the layer
2017-04-27 22:56:55 +02:00
%End
virtual bool isValid() const = 0;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if this is a valid layer. It is up to individual providers
to determine what constitutes a valid layer.
2017-04-27 22:56:55 +02:00
%End
virtual void updateExtents();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Update the extents of the layer. Not implemented by default.
2017-04-27 22:56:55 +02:00
%End
2017-04-27 22:56:55 +02:00
virtual bool setSubsetString( const QString &subset, bool updateFeatureCount = true );
%Docstring
2017-12-15 10:36:55 -04:00
Set the subset string used to create a subset of features in
the layer. This may be a sql where clause or any other string
that can be used by the data provider to create a subset.
Must be implemented in the dataprovider.
2017-04-27 22:56:55 +02:00
%End
virtual bool supportsSubsetString() const;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Returns true if the provider supports setting of subset strings.
2017-04-27 22:56:55 +02:00
%End
virtual QString subsetString() const;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Returns the subset definition string (typically sql) currently in
use by the layer and used by the provider to limit the feature set.
Must be overridden in the dataprovider, otherwise returns a null
QString.
2017-04-27 22:56:55 +02:00
%End
virtual QStringList subLayers() const;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Sub-layers handled by this provider, in order from bottom to top
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Sub-layers are used when the provider's source can combine layers
it knows about in some way before it hands them off to the provider.
.. seealso:: SUBLAYER_SEPARATOR
2017-04-27 22:56:55 +02:00
%End
static QString SUBLAYER_SEPARATOR;
virtual QStringList subLayerStyles() const;
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Sub-layer styles for each sub-layer handled by this provider,
in order from bottom to top
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Sub-layer styles are used to abstract the way the provider's source can symbolise
layers in some way at the server, before it serves them to the provider.
2017-04-27 22:56:55 +02:00
%End
virtual uint subLayerCount() const;
2017-04-27 22:56:55 +02:00
%Docstring
Returns the number of layers for the current data source
2017-04-27 22:56:55 +02:00
%End
virtual void setLayerOrder( const QStringList &layers );
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Reorder the list of layer names to be rendered by this provider
(in order from bottom to top)
2017-04-27 22:56:55 +02:00
.. note::
layers must have been previously added.
%End
virtual void setSubLayerVisibility( const QString &name, bool vis );
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Set the visibility of the given sublayer name
2017-04-27 22:56:55 +02:00
%End
virtual QString name() const = 0;
2017-04-27 22:56:55 +02:00
%Docstring
Returns a provider name
2017-12-15 10:36:55 -04:00
Essentially just returns the provider key. Should be used to build file
dialogs so that providers can be shown with their supported types. Thus
if more than one provider supports a given format, the user is able to
select a specific provider to open that file.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
\note
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Instead of being pure virtual, might be better to generalize this
behavior and presume that none of the sub-classes are going to do
anything strange with regards to their name or description?
2017-04-27 22:56:55 +02:00
%End
virtual QString description() const = 0;
2017-04-27 22:56:55 +02:00
%Docstring
Returns description
2017-04-27 22:56:55 +02:00
Returns a terse string describing what the provider is.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
\note
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Instead of being pure virtual, might be better to generalize this
behavior and presume that none of the sub-classes are going to do
anything strange with regards to their name or description?
2017-04-27 22:56:55 +02:00
%End
virtual QString fileVectorFilters() const;
2017-04-27 22:56:55 +02:00
%Docstring
Returns vector file filter string
2017-12-15 10:36:55 -04:00
Returns a string suitable for a QFileDialog of vector file formats
supported by the data provider. Naturally this will be an empty string
for those data providers that do not deal with plain files, such as
databases and servers.
2017-04-27 22:56:55 +02:00
.. note::
It'd be nice to eventually be raster/vector neutral.
%End
virtual QString fileRasterFilters() const;
2017-04-27 22:56:55 +02:00
%Docstring
Returns raster file filter string
2017-12-15 10:36:55 -04:00
Returns a string suitable for a QFileDialog of raster file formats
supported by the data provider. Naturally this will be an empty string
for those data providers that do not deal with plain files, such as
databases and servers.
2017-04-27 22:56:55 +02:00
.. note::
It'd be nice to eventually be raster/vector neutral.
%End
virtual void reloadData();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Reloads the data from the source. Needs to be implemented by providers with data caches to
synchronize with changes in the data source
2017-04-27 22:56:55 +02:00
%End
2014-01-27 09:22:24 +01:00
virtual QDateTime timestamp() const;
2017-04-27 22:56:55 +02:00
%Docstring
Time stamp of data source in the moment when data/metadata were loaded by provider
%End
2014-01-27 09:22:24 +01:00
virtual QDateTime dataTimestamp() const;
2017-04-27 22:56:55 +02:00
%Docstring
Current time stamp of data source
%End
2014-01-27 09:22:24 +01:00
virtual QgsError error() const;
2017-04-27 22:56:55 +02:00
%Docstring
Gets current status error. This error describes some principal problem
2017-12-15 10:36:55 -04:00
for which provider cannot work and thus is not valid. It is not last error
after accessing data by block(), identify() etc.
2017-04-27 22:56:55 +02:00
%End
virtual void invalidateConnections( const QString &connection );
%Docstring
2017-12-15 10:36:55 -04:00
Invalidate connections corresponding to specified name
2017-04-27 22:56:55 +02:00
.. versionadded:: 2.16
%End
2014-01-27 09:22:24 +01:00
virtual bool enterUpdateMode();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Enter update mode.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
This is aimed at providers that can open differently the connection to
the datasource, according it to be in update mode or in read-only mode.
A call to this method shall be balanced with a call to leaveUpdateMode(),
if this method returns true.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Most providers will have an empty implementation for that method.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
For backward compatibility, providers that implement enterUpdateMode() should
still make sure to allow editing operations to work even if enterUpdateMode()
is not explicitly called.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Several successive calls to enterUpdateMode() can be done. So there is
a concept of stack of calls that must be handled by the provider. Only the first
call to enterUpdateMode() will really turn update mode on.
:return: true in case of success (or no-op implementation), false in case of failure.
2017-04-27 22:56:55 +02:00
.. versionadded:: 2.16
%End
virtual bool leaveUpdateMode();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Leave update mode.
This is aimed at providers that can open differently the connection to
the datasource, according it to be in update mode or in read-only mode.
This method shall be balanced with a successful call to enterUpdateMode().
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Most providers will have an empty implementation for that method.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
Several successive calls to enterUpdateMode() can be done. So there is
a concept of stack of calls that must be handled by the provider. Only the last
call to leaveUpdateMode() will really turn update mode off.
2017-04-27 22:56:55 +02:00
2017-12-15 10:36:55 -04:00
:return: true in case of success (or no-op implementation), false in case of failure.
2017-04-27 22:56:55 +02:00
.. versionadded:: 2.16
%End
void setProviderProperty( ProviderProperty property, const QVariant &value );
%Docstring
2017-12-15 10:36:55 -04:00
Allows setting arbitrary properties on the provider.
It depends on the provider which properties are supported.
2017-04-27 22:56:55 +02:00
.. versionadded:: 2.16
%End
QVariant providerProperty( ProviderProperty property, const QVariant &defaultValue = QVariant() ) const;
%Docstring
Gets the current value of a certain provider property.
2017-12-15 10:36:55 -04:00
It depends on the provider which properties are supported.
2017-04-27 22:56:55 +02:00
.. versionadded:: 2.16
%End
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
virtual void setListening( bool isListening );
%Docstring
2017-12-15 10:36:55 -04:00
Set whether the provider will listen to datasource notifications
If set, the provider will issue notify signals.
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
2017-12-15 10:36:55 -04:00
The default implementation does nothing.
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`notify`
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
.. versionadded:: 3.0
%End
virtual QgsLayerMetadata layerMetadata() const;
%Docstring
Returns layer metadata collected from the provider's source.
Individual data providers must implement this method if they support collecting metadata.
.. seealso:: :py:func:`writeLayerMetadata`
.. versionadded:: 3.0
%End
virtual bool writeLayerMetadata( const QgsLayerMetadata &metadata );
%Docstring
Writes layer ``metadata`` to the underlying provider source. Support depends
on individual provider capabilities.
Returns true if metadata was successfully written to the data provider.
.. seealso:: :py:func:`layerMetadata`
.. versionadded:: 3.0
%End
signals:
void fullExtentCalculated();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
This is emitted whenever the worker thread has fully calculated the
PostGIS extents for this layer, and its event has been received by this
provider.
2017-04-27 22:56:55 +02:00
%End
void dataChanged();
2017-04-27 22:56:55 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
This is emitted whenever an asynchronous operation has finished
and the data should be redrawn
2017-04-27 22:56:55 +02:00
2017-12-19 11:43:52 -04:00
When emitted from a :py:class:`QgsVectorDataProvider`, any cached information such as
2017-12-15 10:36:55 -04:00
feature ids should be invalidated.
2017-04-27 22:56:55 +02:00
%End
void notify( const QString &msg );
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
%Docstring
2017-12-15 10:36:55 -04:00
Emitted when datasource issues a notification
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
2017-12-05 20:04:14 -04:00
.. seealso:: :py:func:`setListening`
[FEATURE] layer refresh and trigger actions on provider notification [needs-docs] In vector layer properties (only usefull for postgres datasources) **in the rendering tab** A "Refresh layer on notification" checkbox has been added to refresh layer on provider notification. For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients, a refresh of the layer will occur. If the "Only if message is" checkbox is checked, the notification will trigger the refresh only if the message contend is the one specified, e.g. if the user enters "refresh" in the box right next to the "Only if message is" checkbox, then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';` won't. **in the actions tab** A column "On notification" has been added, the action editor widget a has text field "Execute if notification message matches" to specify a filter for notification from the provider. The filter is a Perl-type regex. Note that, as opposed to the "layer refresh" that Exemple: - QGIS side "Execute if notification message matches" `^trigger my action` - Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action - Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action - Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited, the last notification would have triggered the action because the notification message contains the `trigger my action` A new qgis variable `notification_message` is available for use in actions, it holds the contend of the notification message. To continue with the previous exemple, if the action is of python type with the code: ```python print('[% @notification_message %]') ``` The three notifictions above will result in two printed lines ``` trigger my action trigger my action some additional data ``` User Warning: For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has "On notification" specified, a new connection to the database is made to listen to postgres notifications. This olds even if transaction groups are enabled at the project level. Note that once the notification mechanism is started in a QGIS session, it will not stop, even if there is no more need for it (Refresh layer on notification" unchecked and no "On notification" in any action). Consequently the connection listening to notification will remain open. IMPLEMENTATION DETAILS: A notify signal has been added to the abstract QgsVectorDataProvider along with a setListening function that enables/disble the notification mechanism. For the moment only the postgres provider implements the notification. QgsAction has a notificationMessage member function that holds the regex to match to trigger action QgsActionManager becomes a QObject and is doing the filtering and execute actions on notifications. The notification notion extends beyond SRGBD servers (postgres and oracle at least have the notify) and the "watch file" in the delimitedtext provider could also benefit from this interface. For the postgres provider a thread is created with a second connection to the database. This thread is responsible for listening postgres notifications. It would be nice to avoid the creation of one listening chanel per provider in the case transaction groups are enabled. Please note that when listening starts (a thread and connection is created in the postgres provider) it cannot be stopped by removing the connected actions or unchecking the refresh check box. Indeed, since we don't know who needs the signals, we dont't want to stop the service. The service will not restart in the next qgis session though. If this behavior is not deemed appropriate, we could use ``` int QObject::receivers ( const char * signal ) const ``` and have QgsDataProvider::setListening return a bool to tell the caller if the signal has actually been closed.
2017-09-08 16:42:30 +02:00
.. versionadded:: 3.0
%End
protected:
2017-04-27 22:56:55 +02:00
void appendError( const QgsErrorMessage &message );
%Docstring
Add error message
%End
void setError( const QgsError &error );
%Docstring
Sets error message
2017-04-27 22:56:55 +02:00
%End
};
2017-04-27 22:56:55 +02:00
/************************************************************************
* This file has been generated automatically from *
* *
* src/core/qgsdataprovider.h *
* *
* Do not edit manually ! Edit header and run scripts/sipify.pl again *
************************************************************************/