Using c:sort with c:join - Sort by join field?

I am a little confused if the following functionality exists in the API or not. Say I make this query:

guild_roster?c:limit=100&c:show=guild_id,rank&c:join=guild^inject_at:guild_id^show:name'guild_id

And I wanted to sort by guild.name inside the guild_id_join_guild hash how might this be done from the query? I have tried using:

• c:sort=name , c:sort=guild.name , c:sort=guild_id.name - Returns invalid search term
• c:join addition like: c:join=guild^on:guild_id^sort=name - Ignored (though from the API I did not think this would work anyway)

Ideally the sort would be something like:

Code:

{    {          "character_id" : ######,          "guild_id" :          {              "name" : ***** // A              "guild_id" : #####          },          "rank" : #    },    {          "character_id" : ######,          "guild_id" :          {              "name" : ***** // B              "guild_id" : #####          },          "rank" : #    }, ...}

I used the guild collections as examples because character is done. My application for this kind of sort ultimately would be a sorted guild roster hash in the form:

Code:

GuildRoster ={    character.name =>{"id" => character_id, ...}, ...}

I could do all of this in code but was looking to see if the c:sort can help with this process. Any idea if c:sort can be used with c:join in this way?

 

Sorting on a joined column is not currently supported. You can currently only sort on fields of the base type, in your case guild_roster. If you flip your query around and search on guild first you could sort on name:

http://census.daybreakgames.com/s:example/get...&c:sort=lower_name&c:join=guild_roster^list:1

 

I did not want to include this query at the time because the character collection was down. However this is an idea of what I would want to do:

guild_roster?guild_id=########&c:limit=500&c:show=character_id,rank&c:join=character^inject_at:character_id^show:name'character_id

I wanted to sort by character_id.name. I could have used the character collection if guild_id was still available but with that removed I see no way I could have the API sort unless by join fields.

With guild_id in the character collection I could do:

character?guild_id=########&c:limit=500&c:show=name,character_id&c:join=guild_roster^inject_at:character_id^show:rank'character_id&c:sort=name

So I guess I would suggest instead that guild_id be added back to the character collection for applications like this if sorting by join fields won't be possible.

 

People want to be able to get the roster of a guild, yet this seems to be difficult to do in 1 query. Can we either make guild_roster return the entire roster of a guild ( http://census.daybreakgames.com/get/dcuo/guild_roster/?name=Munchkins&world=107 ) or get rid of guild_roster altogether and put the roster ON the guild collection?

 

Well I can get the entire guild roster with the guild_roster collection but without guild_id being available in other collections or guild_roster missing key fields for sorting and polling it does make it harder to deal with.

The example I gave was one of them but I was working with feats shortly after this and I had to join the feat and characters_completed_feat with guild_roster and then use code to check if a guild member had a feat and what the name of that feat is.

It would have been great to do this like this:

/guild_roster?guild_id=######&c:limit=5000&c:show=character_id,feat_id&feat_id=######&c:join=feat^inject_at:feat_id^show:name.en'feat_id,character^inject_at:character_id^show:character_id'name

I would not have to even touch the feat and character collections in separate queries or do much processing of the data after the query. I would only need to do a sort but if sorting by join fields would be possible then that would be eliminated as well. (Part of the extra processing has to do with a bug with the characters_active_feat collection which I made a thread about.)

In the end I guess it is down to how much SOE wants an app to do in terms of data processing on their end.