ScoreMore: Creating Baseball ORM and Views

Gearing for Baseball season, ScoreMore Baseball recently just hit it out of the ball park with their app release across all the major mobile platforms.  One of the key differentiators for the app is the use of Couchbase that was discussed over in the ScoreMore with Couchbase Mobile blog.  We will explore now in this blog how the app designed its object mappers and obtain their Views. 

For ScoreMore, the design of the Object Relation Map is to keep a specific attribute for “type” in order to identify the kind of “object” the document is.  In baseball, a team consists of members in various roles.  In the example below, “type”:”coach” is for a document containing all the information for a Coach during the game.  Other roles will be defined by their respective “type”

_{Note: hash and salt are for password storage, _id and _rev are not shown, as those are automatically generated by Couchbase. Human readable versions of _id will be used in future examples, such as “coach_1”}

In some documents, the bottom level node of a structure can be rolled up into an array on the owning document.  The classic example is rolling all addresses of a contact up into an array.  In ScoreMore Baseball, each and every batter's “hit” is rolled up into an array for the game in which they occurred in.  Similarly, for a team, the win-loss record for each season is rolled up into an array on the Team.  This way there is a clear defined first degree of separation and relationship between the attributes.

The team at Score More Baseball also keeps baseball results tidy in their Views, where each View only return documents of a single “type”.  With the Views, the very first check will be an “if-clause” statement, validating against documents that match a certain “type”, either specified by a check against the “type” or against a field that is unique to that document type. An example below is the Spray Chart View where it shows the location of every hit the player has ever made.

The code below first checks if the document (in this case, a game), contains an array of hits for the home team or for the away team while omitting the documents generated by the Sync Gateway. It then iterates through all those hits, and if the search parameters of the Player (specified by 'playerid') for the given season (specified by 'yearid') match the hit, then the 'hit' is added to the result set. Each hit location has an 'x' and 'y' set as well as a 'type', indicating if the hit was a fly ball, line drive, or ground ball.

For example, the spray chart below shows the location of all the hits of “player_1” in the 2015 season by having (key=[“player_1”, 2015])   Red dots represent fly balls, white dots are line drives, and yellow dots are ground balls.

Lastly, on the client side, ScoreMore used JavaScript structures that are in effect, object representations of the various document types available: Coach, Player, Team, Game, etc. The constructors for each of these object structures take the returned results from the View, and map those to the object properties. Going in the other direction (storing to the database from the app), JSON.stringify is used to go from the object structure to the JSON format that Couchbase is expecting for the POST operation.

Hear how Couchbase Mobile provided the ScoreMore team with the technology tools needed to hit it out of the ball park over at the Coffee on Couchbase:  ScoreMore with Couchbase Mobile Blog and be sure to grab the app that is available now for Android, iOS, and BlackBerry.