Talk:Darkcanuck/RRServer/Query

Desired queries

I'm currently interested in queries to enable tweets about RoboRumble entrants once they've achieved a stable rating. For that, I think I'd need the following:

• PARAMS: Bot/Version, Rumble; RETURN: Battle count
• PARAMS: Bot/Version, Rumble; RETURN: APS
• PARAMS: Bot/Version, Rumble; RETURN: Ranking (eg, 9th)

These might be nice, so I'll post them for sake of brainstorming, but they're not needed by me:

• PARAMS: Bot/Version, Rumble; RETURN: Glicko-2
• PARAMS: Bot/Version, 1v1 or Melee; RETURN: Lowest weight class
  • Can be deduced from querying with each of the 4 rumbles, anyway.
• PARAMS: Bot/Version, Rumble; RETURN: Pairings complete? (boolean)
  • Can be assumed complete for battle count > 2000.

--Voidious 14:37, 6 August 2009 (UTC)

Any reason you list the first three ones separate? Wouldn't it make sense to have one query get all three of those things about a bot, since a number is so much smaller than a http header, wouldn't it be easier to just get all of those at once? --Rednaxela 21:14, 6 August 2009 (UTC)

No particular reason, it could certainly get them all at once. One potential benefit to separating out battle count is that I wouldn't need APS / ranking until battle count reached a certain threshold, and I think ranking is a lot more overhead than the other two (requires sorting all the bots by APS). --Voidious 21:32, 6 August 2009 (UTC)

One basic query could get you the entire row (minus rank #) from the any rankings table based on bot name and game type. Or you could get the whole table, sort it yourself by whatever column you wish. I'd rather keep the # of query types small and their functions general and then users consuming that data can do sorting, comparing, etc. --Darkcanuck 05:45, 7 August 2009 (UTC)

The one I'd mostly be interested in would be the following:

• PARAMS: Rumble, Timestamp(optional); RETURN: All paring details (bot names, score, survival, maybe battle count) in Rumble (that had a battle since Timestamp).

It would make it easy to get/update test data for doing analysis of how bots do against other bots.

--Rednaxela 15:43, 6 August 2009 (UTC)

Pairing data (ie summarized battles for each pair) or raw battle data? It sounds very expensive... How would you use this? --Darkcanuck 05:45, 7 August 2009 (UTC)

Pairing data, not raw battle data I mean. I was thinking of doing a huge clustering of all 538022 pairings, across 734 dimensions (one for each bot). Once this huge clustering is computed, the cluster centers could be used to categorize bots, and potentially reveal hidden categories of bots that aren't well known on the wiki. I really think the result of such a clustering would be immensely interesting :) --Rednaxela 06:15, 7 August 2009 (UTC)

I'm thinking, some of this stuff could be quite a bit of data. Perhaps it would be better to put it all into a zip file before returning it? --Skilgannon 19:48, 6 August 2009 (UTC)

Err... zip file? A raw deflate or gzip stream would be less overhead and much saner. Zip files are for archiving groups of files, not compress raw data. Actually, if the web server is set up correctly, it can transparently compress anything coming out of it as it sends to the client, so long as the client said in the http header that it accepts compressed responses (which as a note, firefox for one does on any web page). Anyway, might I suggest that maybe the query results should be encoded in JSON, since this is a very simple low-overhead format, which php has a builtin function to serialize to? --Rednaxela 20:57, 6 August 2009 (UTC)

I'm pretty sure my server is setup to send a gzip stream if the client can handle it. No zip files though, just a plain text stream that other apps can consume easily. JSON was exactly what I was thinking, it's a simple structure and already used by ABC's very cool LRP graphs. (try using RatingDetailsJson instead of RatingsDetails to see an example). --Darkcanuck 05:45, 7 August 2009 (UTC)