sfmagic.org Data Structures

23:53 Fri 14 Dec 2007. Updated: 02:24 15 Dec 2007
[, , ]

I’m way behind on data entry for sfmagic.org, so the first thing I need to do to improve it is to get it up to date. It would help to have a better system for entering the data.

One thing that would help a lot: batch entry, so that I could submit a number of results at once and have the site process through them, probably asking for confirmation before actually entering each tournament. Hence a text data format would help a great deal. Ideally, the workflow would be to enter the text data into a single file, have it parse them, have it add any new players encountered in the file, and then add each tournament after confirming that the data is correct.

Because I plan to enter head-to-head information, I think I’d like the reporting format to include that. I’d also like the reporting format, and the underlying data structure that the application will use to store the data before putting it into the tables, to be amenable to use in one-off web pages, with an eye towards a web page that could handle some of the logistics of running a tournament.

That application-level data structure should clearly be JSON. The database side of the structure is already defined for everything except head-to-head results, which I’ll address another time.

What should the JSON structure for a tournament look like? At the top level, it would have tournament details, players, and rounds.

The tournament object would be fairly straighforward:

"tournament_details": {
    "date": "20070815 19:30",
    "id": "20070816a",
    "seeding": "Scatter",
    "players": 8, //this might be an unnecessary data point
    "major_format": "Limited",
    "format": "Booster Draft",
    "type": "Swiss",
    "best_of": 3,
    "rounds": 3, //might also be redundant
    "superset": "TSP",
    "sets": "TSP/FUT/PLC"

Players could be represented by a list of their names. This relies on player names being unique, but that’s an assumption the site makes in any case.

"players": [
        "name": "Derek Jeter",
        "deck": "Blue/Black",
        "rare": "Venser, Shaper Savant",
        "rare_price_at_entry": null,
        "rare_price_current": null
    //7 other similar player objects

After that, I have a choice of representing the results as currently stored in the system, or of representing the results in the individual rounds, and having the system do the work of translating that later. Since I want something that can eventually aid in running drafts, I’ll go with rounds rather than results. Each round is an object, each match is an object:

"rounds": [
        "round": 1,
        "matches" : [
                "players": ["Derek Jeter","Paul O'Neill"],
                "games_won": 2,
                "games_lost": 1,
                "games_drawn": 0,
                "up_if_draw": null //enter player who randomly got paired up in event of draw
            // the other 3 matches go here
    // the other two rounds go here

The system would have to recognize that games_won means games won for player one and lost for player two.

I think that basic structure would cover all of the information. However, it’s long and annoying to have to enter data in JSON. So I need a format for easy entry that could be translated to JSON. Something like this seems viable:

20070816a;20070815 19:30;Scatter;8;Limited;Booster Draft;Swiss;3;3;TSP;TSP/FUT/PLC;
Derek Jeter;Scott Brosius;Chuck Knoblauch;Mariano Rivera;Paul O'Neill;Tinp Martinez;Andy Pettitte;Jorge Posada
(Eight semi-colon-delimited rares)
(Each round would have its own entry like that one)

The translation from that to JSON doesn’t seem too hard, and that does seem like a relatively easy format to write results in.

Writing the code to do that transformation is the fun part—the hard part will still be entering all that data.

2 Responses to “sfmagic.org Data Structures”

  1. Brett Says:

    That does sound like a pain to enter. Wouldn’t it make sense to whip up a simple GUI? You could have drop-down text boxes for most fields (tournament format info, player names, card names), and five checkboxes for the five colors. I don’t think it would be much harder to code up than making a parser for your text format.

    If Python GUI programming isn’t your bag, you could do almost the same thing with a web form.

  2. Tadhg Says:

    Brett: I guess I wasn’t clear enough in my last post—I actually have a fairly good web form for entering tournaments, although it doesn’t deal with head-to-head. But it autocompletes on card names in a rather useful way, has lists of players names, etc., and is fairly optimized for rapid data entry.

    The problem is that it’s very much a one-at-a-time interface. I enter the data, hit submit, wait for the server to process everything, rinse, repeat. I want to create a service that will take a large number of tournaments that I’ve entered into a text file and process them one-by-one, with some vetting. The JSON structure is there to support that vetting/confirmation stage, and also to support some possible other features, such as a page that handles running a pod.

    While text entry has lots of advantages, and is certainly quick and lightweight, as you point out it doesn’t have the lists of player names or card names. I might conceivably end up writing some other piece of UI to make entering those things as easy as they are in the current web form.

    An alternative, which I’ll probably also create, is a version of the current web UI that allows for batching of entries. One advantage of the plaintext format, though, is that I could still enter data for it without a net connection (a condition that, while increasingly rare, does still occur).

Leave a Reply