Long story short, the `layer.committedFeaturesAdded` signal is not fired after `layer.commitChanges()` when in transaction mode.
If the layer is using the `QgsVectorLayerEditBuffer` the `commitedFeaturesAdded` signal is fired.
But if transaction is used and the `layer.editBuffer()` returns `QgsVectorLayerEditPasstrough`, then there is no signal.
The `QgsVectorLayerEditPasstrough` class is quite empty and lacking implementation of these events, so they don't work on layers in a transaction group.
Also, make sure that non enforced constraints
do not block commits and do not report as violated
constraints (Fix#46364).
Followup #46439 because the constraints were
not checked agains the widget value but against
the attribute value.
The method returns TRUE if the layer is a query/sql layer.
This allows to selectively show the "Update SQL Layer..." menu
entry in the legend.
Partial fix for #45796
When features have a temporal "range", we should never treat
that range as inclusive of the end (or we end up with features
appearing in multiple date ranges)
Completes fixes begun by @rduivenvoorde in https://github.com/qgis/QGIS/pull/40989Fixes#38468
Follow up 56f7812ca1e
This commit fixed the ordering of features coming from the
vector layer cache for the attribute table, but came with a massive
speed impact due to the repeated calls QList::contains for
every feature fetched. For any moderately sized table or above
these calls stacked up into multiple minute delays in opening
the table.
Avoid this by tracking the added feature ids in a separate
unordered set, so that we don't need to check through the
ordered list for existing features at all.
Eg a 500k feature gpkg was taking 10 minutes to open the table.
With this optimization that's back down to 20 seconds.
This is not thread safe at all - we cannot access a layer from
an iterator, as iterators may be running on background threads.
Instead use a thread safe approach of storing a QgsVectorLayerFeatureSource
and using that instead
Fixes#38551
class
This avoids an ugly include of qgsvectorlayerexporter.h in
qgsproviderregistry.h/qgsprovidermetadata.h, which in turn
triggers an inclusion of qgsvectorlayer.h and a bunch of
other heavy dependencies.
Changes in the layer API:
* The setDatasource() methods become non-virtual public method
* The virtual private setDataSourcePrivate() method is defined and the provider setDataSource implementations have been moved to this new virtual method
QgsVectorLayer::minimumValue and then QgsVectorLayer::maximumValue
when we need BOTH the min and max value for a field, add an
optimised QgsVectorLayer::minimumAndMaximumValue() method
which can calculate both min and max at the same time in
a single iteration.
Potentially halves the cost of calculating these values whenever
we are forced to do a full iteration to calculate them.
