Bungie-net / api

Resources for the Bungie.net API
Other
1.22k stars 92 forks source link

d2ClanProgressions is not a list. #197

Closed nine13tech closed 6 years ago

nine13tech commented 6 years ago

GroupsV2.getGroup outputs the clan data, like name, about, motto, banner etc. It also gives the Clan Progression, however, it is not an iterable list

           "clanInfo": {
                "d2ClanProgressions": {
                    "584850370": {
                        "progressionHash": 584850370,
                        "dailyProgress": 417750,
                        "dailyLimit": 0,
                        "weeklyProgress": 17750,
                        "weeklyLimit": 100000,
                        "currentProgress": 417750,
                        "level": 4,
                        "levelCap": 6,
                        "stepIndex": 4,
                        "progressToNextLevel": 67750,
                        "nextLevelAt": 125000
                    },

I really want to expect d2ClanProgressions to be a list so I can iterate through the different progression data that all have the same data points (a text book list?!?!)

xlxCLUxlx commented 6 years ago

Hi nine13tech,

You can actually still iterate through the d2ClanProgressions it is just a Dictionary with the key being the progressionHash and the value being

{ "progressionHash": 584850370, "dailyProgress": 417750, "dailyLimit": 0, "weeklyProgress": 17750, "weeklyLimit": 100000, "currentProgress": 417750, "level": 4, "levelCap": 6, "stepIndex": 4, "progressToNextLevel": 67750, "nextLevelAt": 125000 }

You will want to take a look at GroupsV2.GroupV2ClanInfoAndInvestment which defines JSON you are displaying.

I hope this helps!

Regards, xlxCLUxlx

nine13tech commented 6 years ago

I can iterate it, but I still was expecting a "d2ClanProgressions": [ ... ] notation instead of the {...} Which would flow suit for the other lists of data like it. Hence the issue for consistency in returns. But yes, you are correct, it is iterable and I am iterating on it as it stands. Thanks for the help.i will check out the investment data.

xlxCLUxlx commented 6 years ago

Ah... I see what you are going for now. Yeah, I am not sure the reason for the Dictionary implementation rather than just a list. I have noticed a lot of Dictionary implementations since using the OpenAPI spec that was provided. The only thing I can think of if for searching the Dictionary based on the key; however, I usually do the same as you and need to iterate through the objects like in your example because I want them all not a specific one.

vthornheart-bng commented 6 years ago

If it helps, the reason why the dictionary is used in a lot of cases for us is because, early on in the D1 implementation of the API, we found that we were using lists of entities in a lot of places - but in many places (such as this one) the order of the entities wasn't meaningful: rather, it was more important that people had a convenient way to lookup the specific entity being looked for in the list. It ended up being a standard that we sometimes falter on but try to adhere to: if it's a list of references to data about entities and their order isn't important, we return them as a Dictionary keyed by the identifier of the entity for more convenient lookups. If the order does matter, or if the entity doesn't have an identifier that would make lookups matter, then we return them as lists.

There are definitely places where we've made exceptions for this as well - sometimes oversights on my part, and sometimes intentionally for some perceived benefit. But for the most part when you see a Dictionary, you can imply that order doesn't matter and that we were predicting people were more often than not going to do lookups against this data for the specific entities they wanted rather than iterating through the whole set.

xlxCLUxlx commented 6 years ago

Thanks for the explanation! It makes sense to me why you implement a dictionary and is very easy to iterate through in instances where I want everything. As I read your explanation and thought about my own implementation of your API in my code I was wondering about the hashes. Will these remain static for existing items that are defined in the world_sql_content manifest database? The \Destiny2\Milestones\ is another example that is implemented as a dictionary. In this case you have to either iterate through everything and apply logic for what you want or know the specific hashes that you would like to get the values for from the dictionary. Currently, I iterate through everything and apply logic for what I want; however, if hashes are static then I wouldn’t mind defining some constants and pulling based on the key instead. I have never understood though how these are maintained behind the scenes as it looks like GUIDS for images and icons have changed before.

sgtfrankieboy commented 6 years ago

@xlxCLUxlx The hash value is static. Don't expect any of the image urls to be though, they can change from time to time.

vthornheart-bng commented 6 years ago

Yeah, the images have an extremely long-standing bug that we've never taken the time to investigate and fix, in which those file names can change even though the image itself hasn't changed. Unfortunately, it keeps getting lost in our backlog of more immediate things to do... which sucks because it's an awful lot of data for sites or apps to have to go download again if they happen to be pre-fetching the data. I need to look into it.

For Hashes specifically though, they are indeed meant to be immutable. The only time this has bitten us in the butt was in the great Activity renaming of 2015, when the data for a bunch of activities were altered in Destiny 1 in such a way that it actually did change these supposedly-immutable Activities. This caused both BNet and those using the API a good bit of problems, but it should hopefully be something that doesn't happen again.

Now that I'm saying that, I feel certain that I've jinxed us. You should trust the hashes though, we do: at the least, if a hash gets changed out from under us, we'll be screwed as much as you are. ;)