-
Notifications
You must be signed in to change notification settings - Fork 48
Open
Description
Given a job UUID, it may be both faster and more to the point to get the job results from the, well, the actual job results. Currently, the scheduling job results just consist of a boolean, so these would then have to be replaced by the actual schedule(s). The get_schedule and get_forecast endpoints would need to be adapted accordingly. Note that they are both already fetching the job (but just for its timing parameters).
I'm not sure yet whether fetching from Redis should have default priority over fetching from Postgres, or whether it should be made into an explicit choice via a new API parameter.
Some notes:
- Relying on Redis retrieval only is guaranteed to be faster than a Postgres query (by definition, because constructing the Postgres query already relies on fetching the job)
- Job results in Redis only live for a certain time (governed by the
FLEXMEASURES_PLANNING_TTLconfiguration setting), so the job may in principle be gone after a while. Even though I consider it unlikely that an API user tries to fetch an expired job (after, say, a few days), we might still not to fall back to a Postgres query.
Reactions are currently unavailable