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 *
|
|
|
|
************************************************************************/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-09 02:39:15 +00:00
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
class QgsDataProvider : QObject
|
2007-01-09 02:39:15 +00:00
|
|
|
{
|
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
|
|
|
|
|
2007-01-09 02:39:15 +00:00
|
|
|
%TypeHeaderCode
|
2017-04-27 22:56:55 +02:00
|
|
|
#include "qgsdataprovider.h"
|
2007-01-09 02:39:15 +00:00
|
|
|
%End
|
2010-12-14 20:43:51 +00:00
|
|
|
%ConvertToSubClassCode
|
2017-04-27 22:56:55 +02:00
|
|
|
if ( qobject_cast<QgsVectorDataProvider *>( sipCpp ) )
|
2010-12-14 20:43:51 +00:00
|
|
|
{
|
2017-04-27 22:56:55 +02:00
|
|
|
sipType = sipType_QgsVectorDataProvider;
|
2010-12-14 20:43:51 +00:00
|
|
|
}
|
2017-04-27 22:56:55 +02:00
|
|
|
else if ( qobject_cast<QgsRasterDataProvider *>( sipCpp ) )
|
2010-12-14 20:43:51 +00:00
|
|
|
{
|
2017-04-27 22:56:55 +02:00
|
|
|
sipType = sipType_QgsRasterDataProvider;
|
2010-12-14 20:43:51 +00:00
|
|
|
}
|
2018-04-06 16:11:50 +02:00
|
|
|
else if ( qobject_cast<QgsMeshDataProvider *>( sipCpp ) )
|
|
|
|
{
|
|
|
|
sipType = sipType_QgsMeshDataProvider;
|
|
|
|
}
|
2010-12-14 20:43:51 +00:00
|
|
|
else
|
|
|
|
{
|
2017-04-27 22:56:55 +02:00
|
|
|
sipType = 0;
|
2010-12-14 20:43:51 +00:00
|
|
|
}
|
|
|
|
%End
|
2012-09-24 02:28:15 +02:00
|
|
|
public:
|
2007-01-09 02:39:15 +00:00
|
|
|
|
2016-01-04 22:51:18 +11:00
|
|
|
enum DataCapability
|
|
|
|
{
|
|
|
|
NoDataCapabilities,
|
|
|
|
File,
|
|
|
|
Dir,
|
|
|
|
Database,
|
|
|
|
Net
|
|
|
|
};
|
|
|
|
|
2016-05-28 17:30:18 +02:00
|
|
|
enum ProviderProperty
|
|
|
|
{
|
2017-04-27 22:56:55 +02:00
|
|
|
EvaluateDefaultValues,
|
|
|
|
CustomData
|
2016-05-28 17:30:18 +02:00
|
|
|
};
|
|
|
|
|
2018-05-21 11:10:34 +10:00
|
|
|
|
|
|
|
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:10:34 +10:00
|
|
|
};
|
|
|
|
|
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``.
|
2018-05-21 11:10:34 +10:00
|
|
|
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
2017-04-27 22:56:55 +02:00
|
|
|
virtual QString dataSourceUri( bool expandAuthConfig = false ) const;
|
|
|
|
%Docstring
|
2018-05-26 18:44:30 +10:00
|
|
|
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
|
2018-05-26 18:44:30 +10:00
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
2016-07-10 21:30:19 +10:00
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
2016-07-10 21:30:19 +10:00
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
2016-07-10 21:30:19 +10:00
|
|
|
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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
2016-07-10 21:30:19 +10:00
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
2017-11-26 12:23:32 +10:00
|
|
|
.. seealso:: SUBLAYER_SEPARATOR
|
2017-04-27 22:56:55 +02:00
|
|
|
%End
|
2012-09-24 02:28:15 +02:00
|
|
|
|
2017-11-26 12:23:32 +10:00
|
|
|
static QString SUBLAYER_SEPARATOR;
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
virtual uint subLayerCount() const;
|
2017-04-27 22:56:55 +02:00
|
|
|
%Docstring
|
2018-05-25 13:54:27 +10:00
|
|
|
Returns the number of layers for the current data source
|
2017-04-27 22:56:55 +02:00
|
|
|
%End
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
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
|
2012-09-24 02:28:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
virtual QString name() const = 0;
|
2017-04-27 22:56:55 +02:00
|
|
|
%Docstring
|
2018-05-25 13:54:27 +10:00
|
|
|
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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
virtual QString description() const = 0;
|
2017-04-27 22:56:55 +02:00
|
|
|
%Docstring
|
2018-05-25 13:54:27 +10:00
|
|
|
Returns description
|
2017-04-27 22:56:55 +02:00
|
|
|
|
2018-05-25 13:54:27 +10: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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
virtual QString fileVectorFilters() const;
|
2017-04-27 22:56:55 +02:00
|
|
|
%Docstring
|
2018-05-25 13:54:27 +10:00
|
|
|
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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
virtual QString fileRasterFilters() const;
|
2017-04-27 22:56:55 +02:00
|
|
|
%Docstring
|
2018-05-25 13:54:27 +10:00
|
|
|
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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
2010-09-20 11:27:12 +00:00
|
|
|
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
|
2010-09-20 11:27:12 +00:00
|
|
|
|
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
|
2018-05-26 18:44:30 +10:00
|
|
|
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
|
|
|
|
2016-04-11 19:37:03 +02: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
|
2016-04-11 19:37:03 +02:00
|
|
|
|
|
|
|
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
|
2018-05-26 18:44:30 +10:00
|
|
|
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
|
2016-04-11 19:37:03 +02:00
|
|
|
|
[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
|
|
|
|
|
2017-12-02 10:52:58 +10:00
|
|
|
|
2018-02-05 12:57:04 +01:00
|
|
|
virtual QgsLayerMetadata layerMetadata() const;
|
|
|
|
%Docstring
|
2018-02-20 09:59:39 +10:00
|
|
|
Returns layer metadata collected from the provider's source.
|
|
|
|
|
|
|
|
Individual data providers must implement this method if they support collecting metadata.
|
2018-02-05 12:57:04 +01:00
|
|
|
|
2018-02-20 09:59:39 +10:00
|
|
|
.. seealso:: :py:func:`writeLayerMetadata`
|
2018-02-05 12:57:04 +01:00
|
|
|
|
|
|
|
.. versionadded:: 3.0
|
|
|
|
%End
|
2018-02-20 09:59:39 +10:00
|
|
|
|
|
|
|
virtual bool writeLayerMetadata( const QgsLayerMetadata &metadata );
|
2018-02-05 12:57:04 +01:00
|
|
|
%Docstring
|
2018-02-20 09:59:39 +10:00
|
|
|
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.
|
2018-02-05 12:57:04 +01:00
|
|
|
|
|
|
|
.. seealso:: :py:func:`layerMetadata`
|
|
|
|
|
|
|
|
.. versionadded:: 3.0
|
|
|
|
%End
|
|
|
|
|
2007-01-09 02:39:15 +00:00
|
|
|
signals:
|
|
|
|
|
2012-09-24 02:28:15 +02:00
|
|
|
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
|
2007-01-09 02:39:15 +00:00
|
|
|
|
2013-01-28 01:39:58 +01:00
|
|
|
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
|
2013-01-28 01:39:58 +01:00
|
|
|
|
2017-10-09 10:21:35 +10:00
|
|
|
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
|
|
|
|
|
|
|
|
|
2016-01-04 22:51:18 +11:00
|
|
|
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
|
2018-05-25 13:54:27 +10:00
|
|
|
Sets error message
|
2017-04-27 22:56:55 +02:00
|
|
|
%End
|
|
|
|
|
2007-01-09 02:39:15 +00:00
|
|
|
};
|
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 *
|
|
|
|
************************************************************************/
|