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)
Intended as a registry for the various processing components,
including providers, algorithms and various parameters and outputs.
Currently handles only registration of providers, as a step toward
removing processing's algList (this requires first porting
the algorithm class to c++)
A QgsProcessingRegistry instance is attached to QgsApplication,
and is retrieved by QgsApplication::processingRegistry()
