This function (available only in Processing expressions for now),
allows loading a map layer via a source string and provider name.
It is designed to allow use of the expression functions which
directly reference map layers (such as the aggregate functions)
with a hardcoded layer path, eg. then permitting these functions
to be used outside of a project (such as via the qgis_process tool)
* mesh expression $vertex_as_point $vertex_Z_value
* functions help
* SIP, doc and indentation
* fix SIP
* fix help file
* change function name and add Meshes group description
* fix typo
* fix strings and docs
* typo
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....
stage, be more intelligent about compiling AND or OR nodes
We can take advantage of the fact that and AND node will ALWAYS
be false if either input node is static and evaluates to FALSE,
and that OR nodes will always be true if either input is static
and evaluates to TRUE.
In some cases this allows us the shortcut and cut out non-static
nodes during preparation, resulting in faster evaluation and
more easily compiled expressions...
the referenced fields of an expression
Avoids some cases where use of various expression functions which
normally trigger all attributes to be requested, yet can be pre-computed
during prepare stages, cause non-provider fields to be listed in
the referenced columns and accordingly prevent expression compilation.
Notably this can occur when using an expression like:
aggregate( .... , filter:=
"some_child_field"=attribute(@atlas_feature, 'some_atlas_field_name') )
where the whole attribute(@atlas_feature....) part is a constant
static value and can be compiled down to a trivial, index-friendly
"some_child_field"=### filter for the aggregate provider request.
Ultimately giving a big performance boost to the atlas!
check if a node has already been determined to evaluate to a static,
precalculated value, and if so, use this value for the node instead
of attempting to compile the actual contents of the node itself
If we are certain that a node is static and will never change,
the this potentially allows us to short-cut a large part of the
filter expressions content. We already use this short-cut when
evaluating expressions on the QGIS side since years, and its
proven to be stable and reliable. By respecting this during
expression compilation we can offer a huge speed up to certain
filter expressions, especially those which utilise QGIS variables
which are known to be static (such as atlas variables, map scales,
etc). Previously ANY use of a qgis variable would always cause
expression compilation to fail and require a full set of feature
fetching from the provider.
(Resulted in orders of magnitude faster atlas export for a complex
atlas.)
"field=value" type expression, and for condensing a list of similar
expressions to an equivalent "field IN (value, value2,...)" expression
wherever possible
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
