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!
All your uses of toUtf8().data() actually just need a const char*
So use constData() that is semantically more correct, and documented
to be faster.
From http://doc.qt.io/qt-5/qbytearray.html#data
"For read-only access, constData() is faster because it never
causes a deep copy to occur."
Checks whether a function declaration has parameters that are
top level const.
const values in declarations do not affect the signature of a
function, so they should not be put there.
- nodes() return the list of all nodes
- findNodes<T> returns a list of the nodes matching the class
Also drops the regexp for finding form attrs in the value-relation
expressions.
Other minor fixes as suggested in the PR review.
