getStats: where is Year?
Nikolai
Registered Users Posts: 19,035 Major grins
Don, I read the doc that SM only keeps current month worth of stats and "may be previous", but.. don't you think that not having Year in that method makes it kinda funny? Imagine we're in January 2006, and getStats is called with 12 - would it automatically assume that we're talking 2005-12?
My biggest discontent with the absense of Year parameter, however, is heavily linked to the fact that you guys actually do store previous stats. And simply going via standard GET command with a proper year/months parameters takes you right to it.
I do not have a problem if those stats evenually disappear, but I would very much like to have this parameter in API. And if method returns failure for Year=1914 - well, I would know that I do not get those stats.
It's kinda very frustrating having this nice getStats method almost there - and don't have it all the way. Hence I'd have to go though GET, parse HTML - brrr.
Can you add Year - please? :bow
My biggest discontent with the absense of Year parameter, however, is heavily linked to the fact that you guys actually do store previous stats. And simply going via standard GET command with a proper year/months parameters takes you right to it.
I do not have a problem if those stats evenually disappear, but I would very much like to have this parameter in API. And if method returns failure for Year=1914 - well, I would know that I do not get those stats.
It's kinda very frustrating having this nice getStats method almost there - and don't have it all the way. Hence I'd have to go though GET, parse HTML - brrr.
Can you add Year - please? :bow
"May the f/stop be with you!"
0
Comments
No, I'm not adding Year because we *never* store anything past 12 months from the current month. Adding year would be needlessly complicate the API call and my database schema.
The logic for this is pretty simple: if the month you call wraps behind, it's the previous year. It can never be the future year or two years in the past, so the scope is limited, and thus, Months are completely unique. Once you have something that's unique, why add extraneous data?
I fail to see how this is "almost there" and isn't a completely functional API call.
Don
Don,
thank you for the quick response!
I guess I was misled by the way you web interface works, since it *does* accept year.
And being around databases for quite some time I know oh so well that month alone was *never* enough...
But since you *never* store more than 1 year worth of stats - I guess, my further requests/whinings on the topics would be irrelevant..:):
Cheers!
PS
Check out my vikings!
..but I do think I need this.
I'm going to provide an S*E user with stored statistical data, so even if the stats on SM go "out of scope" user would still have local data.
Since it's gonna be for more than one year, I *do* need a year.
And with the current API (image level) I have no clue which year data I would receive as a response
For now l'm going to make a hardcoded "assumption" that any "future" month belongs to the (CurrentYear-1).
But in the long run I would really appreciate if you can add a Year parameter.
You can make it optional (which is totally fine by me, and the current functionality would not change), but if it's provided, I'd like API to honor it and return failure if data is out of scope or plain don't exist.
Please?
Should be AlbumID, correct?
It's never going to happen. Here's your solution:
if($requestMonth > $currentMonth) {
$dataYear = $currentYear - 1;
}
I don't see how that's so tough.
Don
Good catch. Yes. Fixed in our RCS.
Don