This is the 4th part of a series that is following my progress writing a sporting tournament results website. The previous posts in this series can be found at:
In the previous post I explained the basic CRUD operations and interesting routing issues which I found to get the setup I was looking for.
What do I want to achieve?
By the end of this post I will have shown you how I have started the process off of saving match data, how I have chosen a jQuery plugin to aid with the user interface when entering results and my first run at a calculated index to calculate the scores of the matches so far.
Match up details
The arguably most important part of a result stats website is recording the match ups between players and the outcomes. Once this is done the accumulation of the result scores can be implemented. How they are linked to Events is a small issue compared to recording the actual results.
Let’s start with the first part and see how it goes.
So let’s take a look at some of the potential scenarios which could happen and how we will deal with them.
- Single and Doubles match ups with home and away players
- Players could play for the other team due to number match ups
- Players could move club between events
- Ringers could play for any club at any time
To address these issues for each match up there needs to a be a collection of home players and away players. These will be the player records at the point in time at which the match up takes place; the assumption here is the match details won’t be changed after any player changes are made for future events. As we’re using a document database for this and the root is the match then each match will have an instance of the player record at that time point when it occurred.
public class Match : RootAggregate
{
// todo: link to leg
public Classification Classification { get; set; }
public Result Result { get; set; }
public Team WinningTeam { get; set; }
public Team HomeTeam { get; set; }
public Team AwayTeam { get; set; }
public ICollection<Player> HomePlayers { get; set; }
public ICollection<Player> AwayPlayers { get; set; }
public ICollection<Comment> Comments { get; set; }
}
As we can see above we also want a reference to both the home and away teams as well as the winning team. With these details by themselves it would work fine and store the data as required. I have decided to include a Classification enum to make it easier to distinguish between Singles or Doubles match ups (the doubles classification will also be used for 3 on 2 match ups). Due to the issue of 3 on 2 scenarios I’ve kept the players as collections and not explicitly player 1 and player 2. In addition to this I’ve added in an associated “Result” enum value.
public enum Result
{
Incomplete = 0,
Draw,
HomeWin,
AwayWin
}
Having this result value will aid with determining the scores without having to do comparisons between different properties (and potential sub properties) with the aim to make the score index calculations cleaner to read.
Chosen
Chosen is a jQuery plugin to aid with making dropdowns and multi selects more user friendly. I first came across this about 12 months back when it was introduced at work to aid with large dropdown selectors. I decided to use this because I would be selecting individual teams from dropdowns but mainly I would be selecting multiple players from a multi select form input and wanted to make it keyboard friendly to speed up result entry.
As you can see from the small screen shot above it aids with single selection and makes the multi select look cleaner by hiding the “noise” around a default vanilla multi select input form control.
I’m not completely sold this will be the final solution for this issue however it performs as required for now. When I get to working on the UI then I will decide if Chosen is the best way to go or to find an alternative solution.
Score calculations
I had read multiple blog entries on how to do a Map / Reduce index in Raven DB. The general concept of this is to map from a document collection into a simple form with a counter set to 1 which can then be collated and grouped on a property and the counter value can be aggregated to get the full result. This would be fine however I want to count Wins, Losses, Draws and eventually Extras per player in one index. I knew there had to be a way but what was it?
This is when I discovered AbstractMultiMapIndexCreationTask. It works in a similar way to the more basic AbstractIndexCreationTask<T> however instead of having a specific type it “maps” - as defined by T – it allows for a generic method called AddMap<T>. AddMap allows the document type to be defined and then to map into a separate result type (as per the AbstractIndexCreationTask) however you can call this as many times as you like (although I’d imagine there was a limit somewhere either implementation wise or coding standards wise) on any number of document collection types.
Using the AddMap method I added in a “map” for Home wins / losses, Away wins / losses and Draws irrespective of if the player was playing at home or away. I will look to build on this in the future to do more stats for points such as “performs better on home soil” type scenarios.
AddMap<Match>(matches => from match in matches
from player in match.HomePlayers.Select(x => x)
where match.Result == Enumerations.Result.HomeWin
select new Result
{
PlayerId = player.Id,
Wins = 1,
Losses = 0,
Draws = 0
}
);
Above is one of the AddMap calls. Looking at this you can see how we can determine, using a combination of HomePlayers and Result value, that the home players have a win. After another internal code review I have noticed that I didn’t need to do the Select(x => x) however this was left over from earlier development when I was looking at extracting out just the player id and will be updated.
I now had the “mapped” part of the implementation. At this point I have a collection of Result objects with each entry being the result of an individual match per player in that match.
The Reduce part is a simple aggregation using the PlayerId as the group key. This can be easily established using the code below.
Reduce = results => from result in results
group result by result.PlayerId
into r
select new Result
{
PlayerId = r.Key,
Wins = r.Sum(x => x.Wins),
Losses = r.Sum(x => x.Losses),
Draws = r.Sum(x => x.Draws)
};
This will give you a result record per player, who has played at least one match, and their “record” for all events.
At this point it got me the data I wanted but I also wanted to display the player information as well as the results. I first started off looking to do a “join” between the index results and a Player query although I realised I was still thinking too “relational” and needed to find another cleaner option; enter TransformResults.
TransformResults is another function on an index which you can access much like AddMap and Reduce. The tooltip description is a bit cryptic “The result translator definition” but if you allow Visual Studio to work its magic to set out the signature it makes a bit more sense …
TransformResults = (database, results) =>
What this gives you is a delegate in the form of a function expression which takes in IClientSideDatabase and the IEnumerable<T> of your results set which is the outcome of the Reduce we did earlier. The IClientSideDatabase interface, and it’s associated implementation which gets passed in by RavenDB at run time, is purely a lightweight data accessor. As per the documentation the methods are used purely for loading documents during result transformations; perfect! Using this mechanism I was able to Load the player record for each of the result values to be able to access the additional information.
TransformResults = (database, results) => from result in results
let player = database.Load<Player>(result.PlayerId)
select new Result
{
PlayerId = result.PlayerId,
Player = player,
Wins = result.Wins,
Losses = result.Losses,
Draws = result.Draws
};
Conclusion
In this post I have gone over how I’ve decided to model match information, used a jQuery plugin called Chosen to aid with the user experience when adding / editing a match data and how I used a AbstractMultiMapIndexCreationTask derived index in Raven DB to calculate the scores for each player, returning their scores along with their player data.
As always you can follow the progress of the project on GitHub. Any pointers, comments, suggestions please let me know via Twitter or leave a comment on this blog.
