Feature KTPS-1550 add get predictors function

[bremme]

Voor de KTP measurement forecaster en wellicht in algemene zin is het handig om het ophalen van de load en predictors ook los te kunnen doen. Deze PR voegt functionaliteit toe waarmee de predictors los opgehaald kunnen worden.

• Er is een get_predictors functie aan onze Predictor service toegevoegd
• Deze functie wordt nu ook gebruik door de Model input service get_model_input() om niet twee implementaties te hebben.
• De get_predictors() functie heeft een interface waarbij groepen van predictors optioneel gekozen kunnen worden. De groepen zijn
  • weerdata
  • marktdata (apx/elektriciteit en gas prijzen)
  • belastingsprofielen (sjv)
• All predictor functies kunnen zelf resampelen naar een gevraagde forecast resolutie (parameters overgenomen uit get_model_input())
• Een wrapper get_weather_data aan de predictor service toegevoegd. Deze doet alle extra bewerkingen op de weather data zoals het in get_model_input ook gebeurd. Vooral het postprocessen is wellicht niet meer nodig, maar ook een risico om nu te verwijderen.
• Kleine utility functie voor het genereren van een datetime index zodat die altijd hetzelfde is (zou wellicht verder uitgerold kunnen worden)

Kijk met name even naar:

• openstf_dbc.services.model_input.py
• openstf_dbc.services.predictor.py

Laat maar horen of de gekozen implementatie nog beter kan en of als er onbedoelt nog fouten in zitten?

Verder kreeg ik het idee dat er geen gas prijzen waren kan dat kloppen? Misschien meer in het algemeen welke predictor data mag/kan allemaal missen en wat doen we dan. Moet ik bijvoorbeeld allemaal checken en zorgen dat de code nooit crashed bijv?

This should have been written in English perhaps? Let me know if this is an issue so I can translate it.

[bremme]

I noticed the test coverage is quite low. Do we need to address this before merging?

I noticed this as well. It's a bit misleading I guess. These function had no unit test previously, but because I refactored a couple parts all files now count completely as new code. I tried to add a couple basic tests. But its not that straightforward. You either have to mock a every function that makes a database call (most of them). Or you have to mock every call to the database. I agree that ideally this should be tested, but I rather make that a separate task. Perhaps we even need to rethink our architecture to make it better testable in that case.

[sonarcloud[bot]]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

37.2% Coverage
0.0% Duplication