This can be checked by expression functions which are costly to
evaluate (e.g. those which fetch features from a layer) and which
would benefit from early exits when the results of the expression
evaluation are no longer needed (e.g. due to canceling a layer
rendering, etc)
this to abort the acquisition of a connection in the OGR
connection pool
Provide a mechanism to avoid a deadlock when multiple OGR iterators
are trying to obtain a connection to a resource at once.
Refs https://github.com/qgis/QGIS/issues/43572
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
during preparation wherever possible
In many situations we are able to optimize a case when expression
and replace it with a simpler expression node during the preparation
stage. Specifically, if the WHEN conditions are known to be
static values (such as those coming from certain expression context
variables) then we can often replace the whole condition node
with the THEN node of the first static true condition.
E.g.
CASE
WHEN @variable=1 THEN "first_field"
WHEN @variable=2 THEN "second_field"
ELSE "third_field"
END
If @variable is static and '1', then the whole expression node will ALWAYS
be identical to "first_field". Similiarly if @variable='2', then the
whole expression will ALWAYS be "second_field".
If we're able to apply this optimization, then we use the simplified
effective node which represents the whole node during evaluation
time and save a bunch of unnecessary work.
TODO: If we use the effective node during expression compilation
for providers we would be able to handoff more expressions involving
QGIS-side variables and other components to the backend, resulting
in increased use of backend provider indices, etc....
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
