#1 Posted by cbanack (105 posts) - - Show Bio

I've noticed some data that used to be in the web API has disappeared since the beta went live: the "role" or "roles" details that used to appear for each "person" in the "person_credits" of an "issue" resource.

In other words, while the person_credits still provides a list of people who worked on the issue, there is now no way to tell which role that person had (writer, cover artist, editor, etc) for that issue.

#2 Posted by cbanack (105 posts) - - Show Bio

Here's an example where there used to be 'roles' for each 'person' (insert your own API key):


#3 Edited by ringdrossel (3 posts) - - Show Bio

Having the exact same issue over here. How are we supposed to get the role if this is not working? I also checked the new api documentation for the keyword "role" but nothing was found. Please address this problem. Thanks!

#4 Posted by matthewlupo (29 posts) - - Show Bio

Also having the same problem.

#5 Posted by LtSquigs (190 posts) - - Show Bio

Our API guy is aware of it and I believe it working on it

#6 Posted by comictagger (39 posts) - - Show Bio

So I see that roles are now present in the "person_credits", but they seem to be at the wrong level.

The old hierarchy was person_credit->person->roles. The "person" would have a list of "role" objects under it.

As of this afternoon, the structure has changed, and seems a bit odd. Now the "role" is at the same level as the "person", and they seem to be interleaved, with the the relationship of the "person" to the "role" indicated only by the ordering. Is this an intermittent form, or is it complete?

(For an example of how the old way was parsed, see line 281-ish of this file: https://code.google.com/p/comictagger/source/browse/trunk/comictaggerlib/comicvinetalker.py)

#7 Posted by LtSquigs (190 posts) - - Show Bio

@comictagger: This is intentional. We switched it to be at that level because it matches the relationship and the database (the role is at the person_credit level not at the person level, as the role changes per person_credit but not per person)

#8 Edited by comictagger (39 posts) - - Show Bio

Well, I might ask you to reconsider, since the structure of a result set doesn't necessarily have to follow the structure of the underlying DB. Table joins, for example.

Primarily my issue with this new scheme is relying on the ordering, since JSON data is inherently unordered. (http://www.json.org/). That makes it non-trivial to parse.

#9 Edited by comictagger (39 posts) - - Show Bio

Wait, it seems the JSON data is actually structured different from the XML, which I was eyeballing. I just installed a JSON viewer for Chrome to look at it better, and it seems fine. Never mind! :-)

#10 Posted by ringdrossel (3 posts) - - Show Bio

Thx for working on it but now the XML problem is with the structure. Which means the only way to determine the role of the person is by the order?

#11 Posted by ringdrossel (3 posts) - - Show Bio

Is there no more progress on this bug?

#12 Posted by pikahyper (14137 posts) - - Show Bio

@ringdrossel: there's a lot of bugs to fix so I'm guessing the api isn't a big priority since it isn't integral to the site.