Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation checks on timeframe #66

Open
altafan opened this issue Jul 3, 2023 · 0 comments
Open

Validation checks on timeframe #66

altafan opened this issue Jul 3, 2023 · 0 comments
Assignees

Comments

@altafan
Copy link
Contributor

altafan commented Jul 3, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants