I am reading the current value ok.
I am posting a new datapoint ok (getting a status 200 and it shows up on the beeminder website)
But when I immediately read the current value again (a new get request) I get the old current value.
Is something being cached?
The key code is:
b = Beeminder()
print ("Test More start Value:")
print (b.getGoalCurValue("testmore"))
print (b.postGoalNow("testmore","Test Value"))
print ("Test More end Value:")
print (b.getGoalCurValue("testmore"))
It even happens if I create a 2nd Beeminder object to check the curval after the post (and hence should not be caching on my end). If I rerun the script I get the correct new value.
Ah, sort of. The api output is getting the value it’s calling the “current value” from the graphing library, so it won’t be updated until the graph image is regenerated… Also, I just checked the api docs, and they claim this is the value of the most recent datapoint, which is lies! (cc @dreev) – this is not the bare value as entered by the user, but is actually the value plotted on the graph. So, it is post-cumulation, and aggifying. E.g. if it’s a do more cumulative goal, you might enter a 1, but the curval might be 31. Another example of when this might be different from the most recent datapoint entered is on a weight goal. For weight goals only the minimum weight of the day counts, so if you weigh in twice and the second weight is actually higher, the curval will not reflect the new higher weight, but will stick with the original lower weight.
To get the most recent datapoint value you can send param include_datapoints=true and then either skinny=true or datapoints_count=n for some n…
Thanks for this. Been thinking about it some more.
To get the most recent datapoint value you can send param include_datapoints=true and then either skinny=true or datapoints_count=n for some n…
My reading of the docs is that these are only available on “GET /users/u.json”
I’d like to see
Skinny supported on “GET /users/u/goals.json” and “GET /users/u/goals/g.json”
Skinny supported without diff_since. “skinny must be sent along with diff_since. If diff_since is not present, skinny is ignored.” In a script which is short-lived I will only GET the user once so diff_since is not really relevant. It seems an odd kludge to give a fictitious diff_since in order to be able to get the skinny goals and only the last_datapoint rather than lots of extra data.
datapoints_count would also be good to see on “GET /users/u/goals.json”, “GET /users/u/goals/g.json” and “GET /users/u/goals/g/datapoints.json”
It would be good to have a little more flexibility with datapoints_count and skinny. I’d like to be able to get skinny goals and say 10 datapoints (or all datapoints with a daystamp later than y) in one call. That would be to provide an easy way to show miles this week/month/year for example. At the moment I’d be getting all the goal detail and making 2 calls (get goal and get datapoints) which seems slow and costly.
Related request: I often just want to fetch datapoints and not any goal information, but that endpoint doesn’t support either diff_since or datapoints_count.