The id field of the recent_data and last_datapoint of a goal in the API used to be a JSON object with a single field, $oid, e.g. "id": { "$oid": "6554f2dbd4865f355ae30507" }. This is kind of silly, and the recent change to remove this object makes sense. The id field is now a simple string, e.g. "id": "6554f2dbd4865f355ae30507".
This is an improvement, yes, but be aware that it is a breaking change, and specifically it broke some of my code. I don’t want to complain too much about this, because it is definitely an improvement not to have this needless object wrapper. Nevertheless, I do want to put it out there that this is a breaking change that has affected me.
(Specifically, the Altbee pages for specific goals are currently not functional. It’s a trivial fix, but I’m probably not going to get to it for at least a few days.)
Really sorry about that, @zzq! Excerpt from the Discord:
@theospears: I’d file this under “not ideal, but really hard to claim the work to do a gold-standard rollout of this change would have been a good use of time”. Maybe a warning forum post a few days before was the proportionate thing.
me: ah, yeah, sounds right! so, yeah, mea culpa but also, onward to the future
Yeah, all things considered, while it would have been nice to have had a bit of warning, it wouldn’t really have been worth putting much more effort than that into ameliorating the breakage in this case. I’ve made the fix to Altbee, now onward to the future indeed.
It’s actually worse than I previously thought: only goals with datapoints since a certain date use the newer non-nested format. Goals without new data still have a nested object with an "$oid" key in their recent_data.
I can work around this, but it is not so great that I need to do so.
