count query params should be number rather string in /market/price API
Take average price in each time segment interval
Current: Now FCD select price from table using sql In() query for each time interval. which select a single row from each time segment. for interval of 1m one minute it is correct as it contains one entry per minutes.
Issue: For large interval price history like 15m-> Fifteen minutes, 1h-> One hour or 1d -> One day taking a single value mislead the price information. Cause price might move to several direction in the whole time interval.
Expected: For large interval FCD should choose the average price of a given interval segment.
Solution: aggregation by multiple time range segment in a single query is not possible in sql native query. To achieve this, time diff in seconds with the current time is calculated and divided with time interval in seconds. the integer part of the division is the segment which the price entity falls into. Then doing avg aggregation based on the price based on the time segment will provide the expected result.
Fix validation
count
query params should benumber
ratherstring
in/market/price
APITake average price in each time segment interval
Current: Now FCD select price from table using sql In() query for each time interval. which select a single row from each time segment. for interval of
1m
one minute it is correct as it contains one entry per minutes.Issue: For large interval price history like
15m
->Fifteen minutes
,1h
->One hour
or1d
->One day
taking a single value mislead the price information. Cause price might move to several direction in the whole time interval.Expected: For large interval FCD should choose the average price of a given interval segment.
Solution: aggregation by multiple time range segment in a single query is not possible in sql native query. To achieve this, time diff in seconds with the current time is calculated and divided with time interval in seconds. the integer part of the division is the segment which the price entity falls into. Then doing avg aggregation based on the price based on the time segment will provide the expected result.