This commit adds the virtual method for running processing algs
to the base c++ class, and adds the initial framework
for c++ algorithm parameters.
When running an algorithm, a QVariantMap is passed
as the algorithm parameters. The high level API provided
by QgsProcessingParameters should be used to retrieve
strings/layers/doubles/etc from this QVariantMap.
This allows advanced use cases, such as passing QgsProperty
with the QVariantMap for "dynamic" parameters, where the
value should be evaluated for every feature processed.
E.g. if the buffer algorithm uses a dynamic property for distance,
then the distance could be bound to either a field value or
to a custom expression. This gets evaluated before buffering
each feature to allow for advanced variable buffering.
Support for dynamic parameters will be "opt in", and non default.
So algorithms will need to specifically add support for
dynamic properties as required.
This implements an improved version of vector.createVectorWriter
in QgsProcessingUtils. The improved version relies on the
core class QgsVectorLayerImport to create empty layers,
which:
- reduces duplicate code and reuses the mature QgsVectorLayerImport
routines
- avoids manual conversion of field types to destination provider
field types
- potentially allows any writable provider to be used as a feature
sink for algorithms (e.g. output direct to MSSQL/Oracle/db2). This
should work now - it just needs exposing via UI.
Algorithms and other processing code should use this method
(instead of dataobjects.getLayerFromString) to
retrieve layers from a string, as it considers the processing
context and allows resolving strings to temporarily stored layers.
This permits processing models to function correctly when
intermediate results are stored as memory layers. Subsequent
model algorithms can then access these temporary layers as inputs.
All temporary layers will be removed when the context object
is destroyed after the model algorithm is run.
This temporary layer store (a QgsProject) is used as a
store for layers that are added if a parameter that
is evaluated to a layer requires that a new, non-active-project
layer is loaded. It means that these layers will remain accessible
for the duration of the algorithm's execution (or models
execution if an algorithm is run as part of a model), before
being automatically discarded when the QgsProcessingContext
used to run the algorithm/model goes out of scope.
This approach has several benefits:
- it means that algorithms (including c++ algorithms) are able
to use both project and non-project layers without needing
to handle any memory management themselves.
- it means that layers are guaranteed to last for the duration
of a model execution. This is currently an issue where models
which use memory layers as intermediate outputs do not
function correctly as the memory layers are destroyed before
the model has finished executing
- there should be no leakage of layers remaining open
after an algorithm exits
Remove processing vector.uniqueValues/vector.getUniqueValues
and port usage to c++ method
Should be much faster than the python method, as the c++ method takes
advantage of handing off the unique values calculation to the
provider source whenever possible
Also
- simplify and add tests
- remove large memory leak (persistant store of all non-project layers)
- remove broken support for direct loading postgres/virtual layers
by string (Python version was very broken and would never match
a postgres/virtual layer)
