Getting more than expected resolving members

I was expecting only id (behavior on census.daybreakgames.com), but I got 24mb of character data. Am I supposed to get full characters when resolving guild members?

Code:

http://census.daybreakgames.com/get/eq2/guild/#####?c:resolve=members

I know I can resolve additional stuff with

Code:

=members(displayname,type)

etc., but I thought that was including extra data rather than limiting it.

 

Code:

http://census.daybreakgames.com/get/eq2/guild/#####

Is all you need to get the members names and id#'s, as well as some other basic guild info: achievements, their guild cloak info, recruiting text, etc, etc...

If you use "?c:resolve=members" then you will get every detail about every member as well, which can be a very large file for some guilds: Individual achievements, aa's, equipment, appearance, spells, factions, stats, etc, etc.

Now if you were looking for one or two specific things from each character that may not so bad:
I.E. ?c:resolve=members(stats.combat.critchance)

Would give you just each character's crit chance.

Depending on what you're doing (and how often), it would prob be best to cache each char individually rather than trying to parse a 24mb+ file each time.

If you wanted to say look at adornments, reforging changes, and experimentation upgrades then you would pull each char and resolve their equipment.

And I'm sure the others here can elaborate if needed as they are far more proficient using the api than I am.

 

Nocker makes a good point though. For 2 years, c:resolve=members has only resolved a character's GUID. For anything else you want to resolve, you had to add fields to the query. Now, suddenly, you get the entire character record for each character. For a guild with 500 members, it's WHARRGARBL. I know best practices are to only ask for what you need, but the change could affect existing sites.

 

Yea, if you were still using old census.daybreakgames.com you would only get member's ID, name and DBID.

 

I may have to do this as well this week. At least, I can see if there are serious differences and work around them. Are the data sets identical, or close enough? I thought census.daybreakgames.com was still the "more up to date" version.

 

Short version: They both get their data from the same place, the only difference is in the middleware code.

Long version:

Here's my understanding of it.

There's the MongoDB (or whatever they're using these days) that contains the actual data. This gets updates from the game servers and wherever else the data comes from.

There's census.daybreakgames.com. That's got the Python code that takes the requests, converts them to MongoDB calls, then converts the results into the requested format, and returns it to the requester.

Then there's census.daybreakgames.com. That's got the Java code that does the same thing as census.daybreakgames.com, only in Java.

Both of them are now going against the same back end MongoDB data store. Any differences in results should now primarily be in the format differences due to different code bases for the middleware.

 

And the primary query I execute does not work. :/ I'll send mail to data-feedback to see if it can be resolved.

 

data-feedback is where I get most of my answers from as well. If you want to post it here or PM me, I can see if the issue is something I already ran into and worked around or not.

 

Should we NOT be using the "old" census.daybreakgames.com? Is it time to switch?

 

I haven't heard an actual date of when/if they're turning off census.daybreakgames.com, but I have certainly heard that census.daybreakgames.com is the direction they're headed. We switched over to census.daybreakgames.com several months ago just so we could do the transition on our own timeline. Haven't noticed any major impacts from it.

 

The issue was actually easy to resolve. census.daybreakgames.com uses last_update as a floating point value, and using queries like last_update=]1234.5 works. Census uses ts (which data also has) but even though it's a floating point value, it doesn't actually work if you use a floating point query, like ts=]1234.5 -- but ts=]1234 works fine. Odd, but not a total loss.