getStats: where is Year?

NikolaiNikolai 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
"May the f/stop be with you!"

Comments

  • onethumbonethumb Administrators Posts: 1,269 Major grins
    edited April 10, 2005
    Nikolai wrote:
    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.
    I assume, since you weren't clear, you're talking about images.getStats, and not album.getStats?

    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
  • NikolaiNikolai Registered Users Posts: 19,035 Major grins
    edited April 10, 2005
    OK then...
    onethumb wrote:
    No, I'm not adding Year because we *never* store anything past 12 months from the current month.
    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! 1drink.gif

    PS
    Check out my vikings!
    "May the f/stop be with you!"
  • NikolaiNikolai Registered Users Posts: 19,035 Major grins
    edited April 14, 2005
    Sorry to bring this back again..
    ..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 responsene_nau.gif
    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?
    "May the f/stop be with you!"
  • NikolaiNikolai Registered Users Posts: 19,035 Major grins
    edited April 14, 2005
    Typo in doc?
    <TABLE cellSpacing=0 cellPadding=0 width=760 align=center border=0><TBODY><TR vAlign=top align=left><TD width=15>spacer.gif</TD><TD width="100%"><TABLE cellSpacing=0 cellPadding=0 width="100%" border=0><TBODY><TR><TD>API Method: smugmug.albums.getStats


    ....

    Arguments:
    • String SessionID
    • int ImageID
    • int Month
    • int Year
    </TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
    Should be AlbumID, correct?
    "May the f/stop be with you!"
  • onethumbonethumb Administrators Posts: 1,269 Major grins
    edited April 14, 2005
    Nikolai wrote:
    ..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 responsene_nau.gif
    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?

    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
  • onethumbonethumb Administrators Posts: 1,269 Major grins
    edited April 14, 2005
    Nikolai wrote:
    Should be AlbumID, correct?

    Good catch. Yes. Fixed in our RCS.

    Don
Sign In or Register to comment.