Closed fkroeber closed 1 month ago
Something that remains to be included...
With the introduction of the FakeProcessor the cache_data
parameter is completely decoupled from the preview_run
in recipe.py. However for the QueryProcessor in core.py, the preview run is still a pre-requisite for building a cache. The QueryProcessor can't utilise an existing initialised cache object when it's run in preview mode. This makes the previews unnecessarily slow.
Since the cache initialisation doesn't require a preview run anymore but can be realised via FakeProcessor in a more efficient manner, preview run and cache should also be decoupled in core.py. Specifically, the handle_layer method needs to be adjusted by omitting the self._preview conditioning.
The latest modification tackles the decouping of preview_run
and cache_data
as discussed previously. The preview_run will now behave the same way a normal run in respect to the cache utilisation (i.e. if a cache from a previous FakeProcessor run is provided it will be used, otherwise the cache will be ignored).
Description
This PR introduces the FakeProcessor class which enables simulated executions of recipes without actually loading or processing any data. This is useful for two applications:
cache_data
parameter frompreview_run
in recipe.py. The data cache can now be initialised via a FakeProcessor run, which is significantly faster than the existing necessity to have a preview run. Accordingly, the default forcache_data
can also be set to True. Note that the functionality ofpreview_run
has been changed in that it now only executes the preview run which is no longer automatically followed by a main run with native resolution.Type of change
Select one or more relevant options:
Checklist: