Member Function Documentation

Returns true in case of success and false in case of failure. If attributes are added using this method then QgsVectorLayer::updateFields() must be called manually to ensure that the layer's field are correctly reported.

This should succeed if the provider reports both the ChangeAttributeValues and ChangeGeometries capabilities. Providers which report the ChangeFeatures capability implement an optimised version of this method.

Parameters

attr_map

a map containing changed attributes

geometry_map

A QgsGeometryMap whose index contains the feature IDs that will have their geometries changed. The second map parameter being the new geometries themselves

Returns any literal default values which are present at the provider for a specified field index.

Important - this should ONLY be called when creating an attribute to insert directly into the database. Do not call this method for non-feature creation or modification, e.g., when validating an attribute or to compare it against an existing value, as calling it can cause changes to the underlying data source (e.g., Postgres provider where the default value is calculated as a result of a sequence). It is recommended that you instead use the methods in QgsVectorLayerUtils such as QgsVectorLayerUtils::createFeature() so that default value handling and validation is automatically carried out.

Return feature source object that can be used for querying provider's data.

The returned feature source is independent from provider - any changes to provider's state (e.g. change of subset string) will not be reflected in the feature source, therefore it can be safely used for processing in background without having to care about possible changes within provider that may happen concurrently. Also, even in the case of provider being deleted, any feature source obtained from the provider will be kept alive and working (they are independent and owned by the caller).

Sometimes there are cases when some data needs to be shared between vector data provider and its feature source. In such cases, the implementation must ensure that the data is not susceptible to run condition. For example, if it is possible that both feature source and provider may need reading/writing to some shared data at the same time, some synchronization mechanisms must be used (e.g. mutexes) to prevent data corruption.