We need to add some validation checks on the usage of the timeframe when fetching prices and balances so that the client is forced to use reasonable timeframes based on the given timerange.
Neither we can afford, nor it makes sense, for example, to use a timeframe of minute in case the timerange is a "big one" like LAST_YEAR, ALL or event LAST_MONTH.
We already enforce at app level that the timeframe can't be larger than the timerange, we should also add sanity checks to make sure it is not too small also.
This could be a reasonable set of value timeframe can assume depending on timerange:
timerange
timeframes
LAST HOUR
1m
LAST 3 HOURS
1m, 1h
LAST_DAY
1h, 4h
LAST MONTH
4h, 1d, 1w
LAST 3 MONTHS
1d, 1w
LAST_YEAR
1w, 1m
ALL
1w, 1m
YEAR_TO_DATE
?
Since YEAR_TO_DATE depends on when it is called, the timeframe can assume any of the value of the table based on the time passed from the beginning of the year.
We need to add some validation checks on the usage of the timeframe when fetching prices and balances so that the client is forced to use reasonable timeframes based on the given timerange.
Neither we can afford, nor it makes sense, for example, to use a timeframe of minute in case the timerange is a "big one" like LAST_YEAR, ALL or event LAST_MONTH.
We already enforce at app level that the timeframe can't be larger than the timerange, we should also add sanity checks to make sure it is not too small also.
This could be a reasonable set of value timeframe can assume depending on timerange:
Since YEAR_TO_DATE depends on when it is called, the timeframe can assume any of the value of the table based on the time passed from the beginning of the year.