My Journey with MongoDB

In 2011, I'd been a SQL Server guy (development, DBA and warehousing) for quite some time and I never meant to set out to find a new data store. I was working as a DBA at the time, and we were asked to look into this new data storage technology called Cassandra. At the time you had to build things manually and that was outside of what we did, so we never went anywhere with it.

That quick look however got me looking at other database technologies and and that's when I came across MongoDB. This was around the time that version 1.8 came out. I started looking at MongoDB to see what it was all about. I was still stuck in my relational ways, but thought that there was something to this new tech. I went out and bought Kristina Chodorow's MongoDB: The Definitive Guide and Kyle Banker's MongoDB in Action. After reading through these books and playing around my mind started grasping the concepts and was beginning to break free from the confines of the relational world. I started seeing how denormalizing (storing duplicate data in multiple documents) the data into a single document made sense. You could store all the data that should be together and wouldn't have to pay the overhead of joining tables. The more I worked with MongoDB the more it made sense.

Shortly after this, another team in the company was looking at using MongoDB as a backend data store for a project they were working on. The project was to replicate something similar to Google Analytics that we could put on our client's web sites and custom build tracking for them. Since I wanted to get some practical experience with the technology, I moved over to that team and spent a month building out a prototype of the system. Unfortunately the developer that I was working with on the project had decided to go a different direction and the project was scrapped.

This had given me a taste of what MongoDB could do, and I kept working with MongoDB in a personal capacity for a while. At the end of 2011, MongoDB University released their first two courses and I decided to take M201. I wasn't sure how involved the courses were so I only wanted to take one at a time. After I passed that course, I took M101 (later renamed to M101P) and I passed that course as well. After I completed M101, I reached out to Andrew Erlichson about becoming a TA for the courses. I was brought on and spent the next two years supporting the M101J, M101JS and M201 courses at various times. The education team was a pleasure to work with and I will always be grateful to them for allowing me to spend that length of time with them. I also learned a lot from the students during that time. For my work with the team, they honored me by giving me the first MongoDB DBA certification back in 2013.

After two years of helping out on the education team I made the hard choice to step away from my role as a TA since my available free time shrunk and I felt that I wasn't giving the students (and the other TAs) the time and attention that was required. I however wasn't done with MongoDB by any means.

About four months later, I was contacted to join the MongoDB Advocacy Hub and have been enjoying helping out with promoting MongoDB in various ways. It's been great working the community team members and getting to know them. I'm slowly getting into blogging now with the encouragement from the marketing and community team members at MongoDB. With my work here I have been honored by being chosen as the MongoDB Giant of the Month for January 2016, and most recently was selected to join the MongoDB Masters Program for 2016.

Most recently I have taken over as the Denver/Boulder MongoDB Meet Up Group organizer. This has been a big change for me as I'm more comfortable being behind the scenes, then organizing them and being front and center. It has only been a few months since starting this leg of my journey, but I've met some wonderful people and glad to see the local community coming out and learning from our speakers. If you're ever in the area stop on in.

My journey has taken me along different paths with MongoDB and I'm glad to have traveled them all. I'm not sure where the adventure will take me in the future, but I know that I'll meet great people along the way and will never be alone.

It's interesting looking back, to realize that I came across the product by chance. Had we not taken a look at Cassandra back then, who knows if I would have payed attention to MongoDB. I have stayed with it for five years now because of the value and ease of working with the product, and the great staff and community the company has assembled and built.

Five Easy Ways to Get Started With MongoDB

1. Download the community edition and play

The community edition is available freely and there are installers for all major operating systems (Linux, OS X, Windows and Solaris). This makes getting a system up and running quickly very easy to do. It should only take a few minutes to install MongoDB and you're ready to start playing and learning how to work with the quickest growing and most popular NoSQL database.

2. Work through the getting started guide

MongoDB provides a getting started guide for the `mongo` shell, Python, Java, C++, NodeJS and C#. Working through the examples provided there will get you up and going with the basics in no time. From there you'll be ready to move on to more involved examples and walkthroughs that you might find on the internet.

3. Take a course at MongoDB University

MongoDB has the best set of online learning courses out there. You can learn to code against MongoDB in four different languages currently: Python, Java, NodeJS and .NET. There are two different DBA courses covering basic and advanced topics. There is an advanced level course on cluster management. These courses are seven weeks long, with the exception of the cluster management course which is only two weeks. Having been through most these courses I wholeheartedly recommend them. They are well done and the forums are moderated by a great group of online TAs with deep knowledge in the respective course topics.

4. Read Kristina Chodorow's MongoDB: The Definitive Guide

If you only read one book on MongoDB, this is the book to read. Even though the second edition came out in early 2013 and covers MongoDB 2.6, you will still learn a lot by reading it. This is also a must read for anyone who's looking at studying for the certification exams. Rumor has it that a third edition is in the works, but I've not seen anything definitive on that. Once it comes out, I'll definitely be grabbing a copy as quickly as I can.

5. Join your local MongoDB user group

Perhaps the funnest way to learn MongoDB and how to go from the basics to more advanced topics is to join your local MongoDB User Group (MUG). These groups are frequented by very passionate MongoDB users and you'll find talks ranging from beginning to advanced topics. Equally important to the talks are the conversations you'll have and the friendships you'll make with your fellow community members.

Note that MongoDB makes it easy for anyone to get started with their database and they have built a great community to help get answers to any questions new users might have. Very few products have that type of community support and buy in. In addition to the community, the employees that I have met and worked with are some of the nicest people around. They've always had time to help me through problems in a way that I didn't seem rushed to get out of their hair. If MongoDB fits your use case definitely install it and put it through its paces and you might be surprised at how easy and quick it is to get things running.

Getting distinct values from MongoDB

MongoDB has a function called distinct that allows you get a list of all the distinct values in the given collection for a single key. Let's say that you wanted to see all of the distinct values for the key OffenseTeam in a collection called pbp_2015. You would use the following statement:

db.pbp_2015.distinct("OffenseTeam")

The result of this statement is an array with each distinct value for the given key. Your results would look something like this:

[
  "",
  "WAS",
  "BUF",
  "CLE",
  "NYJ",
  ⋮
  "JAC",
  "MIA",
  "SEA",
  "GB",
  "IND",
  "STL"
]

Note: results truncated for brevity.

You can also provide a query to this function to view the distinct values on a subset of the data.

db.pbp_2015.distinct("OffenseTeam", {"PlayType": "FIELD GOAL", "Quarter": 4, "Down": {"$ne": 4}})

The above shows us which teams attempted to kick a field goal in the fourth quarter of a game, even if it wasn't their final down. The results show that there were a total of 9 teams that did this in the 2015 football year.

[
  "JAC",
  "BAL",
  "NO",
  "TB",
  "CHI",
  "KC",
  "OAK",
  "NYJ",
  "MIN"
]

While this is great for getting distinct values for a single field, what do you do if you need to get a list of the distinct combination of two or more fields?

One option is to use the aggregation framework to get this information.

The following is an example:

db.pbp_2015.aggregate(
    [
        {
            "$match": {
                "PlayType": "FIELD GOAL",
                "Down": {"$ne": 4},
                "Quarter": 4
            }
        },
        {
            "$project": {
                "OffenseTeam": 1,
                "DefenseTeam": 1,
                "_id": 0
            }
        },
        {
            "$group": {
                "_id": {
                    "OffenseTeam": "$OffenseTeam",
                    "DefenseTeam": "$DefenseTeam"
                }
            }
        },
        {
            "$sort": {
                "_id": 1
            }
        }
    ]
)

The above aggregation is similar to the prior distinct command, you can see that we have the same match criteria ({"PlayType": "FIELD GOAL", "Down": {"$ne": 4}, "Quarter": 4}). This time however we want to see not only the offensive team, but the defensive team as well. Since those are the only fields we care about, we will $project them out. Next we will group on OffsenseTeam and DefenseTeam by combining them into compound _id key to get our list. Finally we'll sort documents on _id to make it easier to read the data.

The results look like the following:

{
  "waitedMS": NumberLong("0"),
  "result": [
    {"_id": {"OffenseTeam": "BAL", "DefenseTeam": "PIT"}},
    {"_id": {"OffenseTeam": "BAL", "DefenseTeam": "SD"}},
    {"_id": {"OffenseTeam": "BAL", "DefenseTeam": "STL"}},
    {"_id": {"OffenseTeam": "CHI", "DefenseTeam": "DET"}},
    {"_id": {"OffenseTeam": "CHI", "DefenseTeam": "OAK"}},
    {"_id": {"OffenseTeam": "JAC", "DefenseTeam": "BAL"}},
    {"_id": {"OffenseTeam": "JAC", "DefenseTeam": "IND"}},
    {"_id": {"OffenseTeam": "KC", "DefenseTeam": "CHI"}},
    {"_id": {"OffenseTeam": "MIN", "DefenseTeam": "CHI"}},
    {"_id": {"OffenseTeam": "NO", "DefenseTeam": "ATL"}},
    {"_id": {"OffenseTeam": "NO", "DefenseTeam": "DAL"}},
    {"_id": {"OffenseTeam": "NO", "DefenseTeam": "NYG"}},
    {"_id": {"OffenseTeam": "NYJ", "DefenseTeam": "NE"}},
    {"_id": {"OffenseTeam": "OAK", "DefenseTeam": "DEN"}},
    {"_id": {"OffenseTeam": "TB", "DefenseTeam": "HOU"}}
  ],
  "ok": 1
}

Here you can see that while there were 9 teams that kicked a field goal in the fourth quarter even though they weren't facing a fourth down at the time, several teams did this in multiple games (BAL, CHI, JAC, and NO).

As you can see, you can use the aggregation framework to get the distinct values over multiple keys. This information can be used for a variety of purposes such as the case we used it above. Another use would be to use this to determine the selectivity of keys in an index.

Data for the samples can be found here. The data was cleaned up using code from this MongoDB blog post.

Book Review: Moodle Course Design Best Practices

Recently I was given a reviewer's copy of Moodle Course Design Best Practices from the publisher Packt Pub. The fact that I was given a copy of the book in exchange for a written review has in no way influenced my rating of the book.

Moodle Course Design Best Practices by Susan Smith Nash and Michelle Moore was a fairly quick read that gives a high level introduction on how to set up courses for a few different situations using the Moodle platform.

The first four chapters give guidelines about using Moodle, how to plan and organize your course and finally some best practices in content delivery. These cover topics such as accessibility (offering your content in different formats so those with disabilities can partake in the course), how the platform is laid out, etc.

The next four chapters talk about different learning situations: Independent Study, Teacher-Student interactive courses, Project Based and Online Communities. Each of these chapters talk about the different areas you should include while setting your course up. Obviously the authors can only discuss this at a high level as each course will be different and there will be different requirements.

Overall I thought this was a good book and I thought that the authors met the goal they set out to reach with this book. I wish the authors would have been more consistent with their screenshot usage when illustrating topics. If you want to get an overview of Moodle and get some ideas of how to set up your course with it, this book should help.

For those who like to see actual ratings, I give the book a 4 out of 5 stars.

Book Review: Getting Started with MariaDB

Recently I was given a reviewer's copy of Getting Started with MariaDB from the publisher Packt Pub. The fact that I was given a copy of the book in exchange for a written review has in no way influenced my rating of the book.

Getting Started with MariaDB by Daniel Bartholomew is a quick introduction to MariaDB. At 100 pages in total (including front and back matter), it obviously cannot go deep in depth about things and must refer you out to the official documentation.

I liked the fact that the author took to the time to walk through examples of setting MariaDB up on Windows, Mac and Linux (sections for Debian based, Red Hat based and general). Chapter 5 is the most useful chapter as it is where you get to see working examples of using MariaDB.

While the book is a good introduction I felt that some things were mentioned that someone new to MariaDB wouldn't need to know. Things like the configuration file (my.ini/my.cnf) are mentioned but the author didn't talk about even the basic entries you might want to put in there. He also has a couple pages talking about the need for security at all levels (internet, intranet, building and server) which while is true, I didn't think that it warranted the mention in an introductory book. And sadly enough this is all mentioned before you learn how to perform basic CRUD operations. :(

One other thing that I found interesting is there is only the briefest mentions of indexing which I feel is a more important topic to a beginner than security and maintenance. Granted that in such a short book you can't put everything in, but indexing is a very important topic and is something someone new to databases needs to know about.

Overall this book should come in handy for someone new to MariaDB, and databases in general, that want to learn the very basics of this database server. However if you have any knowledge of databases already (especially MySQL which MariaDB is based off of), you will want to pass on this book.

For those who like to see actual ratings, I give the book a 3 out of 5 stars.

MongoDB Aggregation for Justin John Mathews - Part 2

Recently on LinkedIn (and as a follow up to a previous post, Justin John Mathews asked a question about being able to return data in a certain format. The input and output records are below. Input

db.users.insert({ courseId: 1, stDt: new Date(2014, 01, 01), endDt: new Date(2014, 01, 20), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 01, 25), endDt: new Date(2014, 02, 10), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 25), endDt: new Date(2014, 03, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 28), endDt: new Date(2014, 06, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 25), endDt: new Date(2014, 02, 30), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 05, 25), endDt: new Date(2014, 10, 30), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2013, 10, 01), endDt: new Date(2014, 08, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 09, 01), endDt: new Date(2014, 11, 30), active: false });

Output (this is my interpretation as the format he gave was not a valid document)

{
    "result" : {
        "past" : [
            { "endDt" : ISODate("2014-02-20T07:00:00Z"), "active" : false },
            { "endDt" : ISODate("2014-03-10T06:00:00Z"), "active" : false },
            { "endDt" : ISODate("2014-03-30T06:00:00Z"), "active" : false }
        ],
        "current" : [
            { "endDt" : ISODate("2014-04-10T06:00:00Z"), "active" : true },
            { "endDt" : ISODate("2014-07-10T06:00:00Z"), "active" : true },
            { "endDt" : ISODate("2014-09-10T06:00:00Z"), "active" : true }
        ],
        "upcoming": [
            { "endDt" : ISODate("2014-11-30T07:00:00Z"), "active" : false },
            { "endDt" : ISODate("2014-12-30T07:00:00Z"), "active" : false }
        ]
    }
}

As you can see the dates are broken up into three different categories of past, current and upcoming. After talking with Justin, he would like to see the stDt value as well and he doesn't need the active field any longer. Each category is sorted by the endDt. A course is past if the endDt is less than the current date. It is active if the stDt is less than the current date and the endDt is greater than the current date. It is upcoming if the stDt is greater than the current date.

This is the code that I came up with. It does most of what he's looking for, but no matter what I did, I couldn't get the final grouping to display in the sorted order he was looking for in all categories. I'm sure I'm missing something simple, but when printing out the sorted list before the final grouping everything looks fine, but for some reason it's not getting added to the array in the order that I would imagine it should have been.

db.users.aggregate([
    {
        "$project": {
            "range": {
                "stDt": "$stDt",
                "endDt": "$endDt"
            },
            "_id": 0
        }
    },
    {
        "$group": {
            "_id": null,
            "past": {
                "$addToSet": {
                    "$cond": [
                        {"$lt": ["$range.endDt", new Date()]},
                        "$range",
                        null
                    ]
                }
            },
            "current": {
                "$addToSet": {
                    "$cond": [
                        {
                            "$and": [
                                {"$gt": ["$range.endDt", new Date()]},
                                {"$lt": ["$range.stDt", new Date()]},
                            ]
                        },
                        "$range",
                        null
                    ]
                }
            },
            "upcoming": {
                "$addToSet": {
                    "$cond": [
                        {"$gt": ["$range.stDt", new Date()]},
                        "$range",
                        null
                    ]
                }
            }
        }
    },
    {"$unwind": "$past"},
    {"$unwind": "$current"},
    {"$unwind": "$upcoming"},
    {
        "$match": {
            "past": {"$ne": null},
            "current": {"$ne": null},
            "upcoming": {"$ne": null}
        }
    },
    {
        "$sort": {
            "past.endDt": -1,
            "current.endDt": -1,
            "upcoming.endDt": -1
        }
    },
    {
        "$group": {
            "_id": null,
            "past": {"$addToSet": "$past"},
            "current": {"$addToSet": "$current"},
            "upcoming": {"$addToSet": "$upcoming"}
        }
    },
    {
        "$project": {
            "past": 1,
            "current": 1,
            "upcoming": 1,
            "_id": 0
        }
    },
])

And here is the output you get in MongoDB 2.2.x or 2.4.x.

{
    "result" : [
        {
            "past" : [
                {
                    "stDt" : ISODate("2014-02-25T07:00:00Z"),
                    "endDt" : ISODate("2014-03-10T06:00:00Z")
                },
                {
                    "stDt" : ISODate("2014-02-01T07:00:00Z"),
                    "endDt" : ISODate("2014-02-20T07:00:00Z")
                },
                {
                    "stDt" : ISODate("2014-03-25T06:00:00Z"),
                    "endDt" : ISODate("2014-03-30T06:00:00Z")
                }
            ],
            "current" : [
                {
                    "stDt" : ISODate("2014-03-25T06:00:00Z"),
                    "endDt" : ISODate("2014-04-10T06:00:00Z")
                },
                {
                    "stDt" : ISODate("2014-03-28T06:00:00Z"),
                    "endDt" : ISODate("2014-07-10T06:00:00Z")
                },
                {
                    "stDt" : ISODate("2013-11-01T06:00:00Z"),
                    "endDt" : ISODate("2014-09-10T06:00:00Z")
                }
            ],
            "upcoming" : [
                {
                    "stDt" : ISODate("2014-06-25T06:00:00Z"),
                    "endDt" : ISODate("2014-11-30T07:00:00Z")
                },
                {
                    "stDt" : ISODate("2014-10-01T06:00:00Z"),
                    "endDt" : ISODate("2014-12-30T07:00:00Z")
                }
            ]
        }
    ],
    "ok" : 1
}

This works well for the small test set you gave, but it might not be that great for larger datasets. You'll need to test that before putting this code into production. If nothing else this gives you an idea of how you can do things with the aggregation framework.

MongoDB Aggregation Query for Justin John Mathews

Recently on LinkedIn, Justin John Mathews asked a question about being able to return data in a certain format. The input and output records are below. Input

db.users.insert({ courseId: 1, stDt: new Date(2014, 01, 01), endDt: new Date(2014, 01, 20), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 01, 25), endDt: new Date(2014, 02, 10), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 25), endDt: new Date(2014, 03, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 28), endDt: new Date(2014, 06, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 02, 25), endDt: new Date(2014, 02, 30), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2014, 05, 25), endDt: new Date(2014, 10, 30), active: false });
db.users.insert({ courseId: 1, stDt: new Date(2013, 10, 01), endDt: new Date(2014, 08, 10), active: true });
db.users.insert({ courseId: 1, stDt: new Date(2014, 09, 01), endDt: new Date(2014, 11, 30), active: false });

Output

{
    "result" : {
        true : [
            { endDt: new Date(2014, 03, 10), active: true },
            { endDt: new Date(2014, 06, 10), active: true },
            { endDt: new Date(2014, 08, 10), active: true },
        ],
        false: [
            { endDt: new Date(2014, 01, 20), active: false },
            { endDt: new Date(2014, 02, 10), active: false },
            { endDt: new Date(2014, 02, 30), active: false },
            { endDt: new Date(2014, 10, 30), active: false },
            { endDt: new Date(2014, 11, 30), active: false }
        ]
    }
}

The code below is one possible solution. I'm not necessarily happy with everything yet, but it does produce the same results as requested, with two small exceptions. First, the code below displays the ISODate instead of the JavaScript date method which I'm assuming is what should have been in the request as you can't return what's shown above. The other small difference is that since I'm using the aggregation framework with MongoDB 2.4.9, the result is a key of result which contains an array of subdocuments as it's value. There were quite a bit of hoops I jumped through to get this solution, and it could probably be cleaned up quite a bit, but I thought I would throw this post together to let him see that it can be done with a single command if you're patient enough to keep tweaking your pipeline. ;)

db.users.aggregate([

    // Project only what we need.
    {
        "$project": {
            "endDt": 1,
            "active": 1,
            "_id": 0
        }
    },

    // Group to true and false buckets. This will give us arrays with null.
    // We'll remove them in a bit.
    {
        "$group": {
            "_id": "$active",
            "true": {
                "$addToSet": {
                    "$cond": [
                        {"$eq": ["$active", true]},
                        "$endDt",
                        null
                    ]
                }
            },
            "false": {
                "$addToSet": {
                    "$cond": [
                        {"$eq": ["$active", false]},
                        "$endDt",
                        null
                    ]
                }
            }
        }
    },

    // We need to unwind our arrays so we can build them back up without the
    // "null" array.
    {"$unwind": "$true"},
    {"$unwind": "$false"},

    // Project out the values. This will give both a true and false key for
    // each item. This builds our arrays up with the proper endDt and
    // active values.
    {
        "$project": {
            "true": {"endDt": "$true", "active": "$_id"}, 
            "false": {"endDt": "$false", "active": "$_id"}
        }
    },

    // Project out a single value to clean up the "issue" a couple steps above.
    {
        "$project": {
            "value": {
                "$cond": [
                    {"$eq": ["$_id", true]},
                    "$true",
                    "$false"
                ]
            }
        }
    },

    // Group things up again to rebuild our arrays.
    // This adds a single "null" entry that will need to be cleaned up.
    {
        "$group": {
            "_id": null,
            "true": {
                "$addToSet": {
                     "$cond": [
                         {"$eq": ["$_id", true]},
                         "$value",
                         null
                     ]
                }
            },
            "false": {
                "$addToSet": {
                    "$cond": [
                        {"$eq": ["$_id", false]},
                        "$value",
                        null
                    ]
                }
            }
        }
    },

    // Unwind our arrays again so we can clean up one more time.
    {"$unwind": "$true"},
    {"$unwind": "$false"},

    // Match only documents where true and false are not null.
    {
        "$match": {
            "true": {"$ne": null},
            "false": {"$ne": null}
        }
    },

    // Sort our items so we can add the to the array in the correct order.
    // I'm not sure why it has to be descending order, but it works.
    {
        "$sort": {
            "true.endDt": -1,
            "false.endDt": -1
        }
    },

    // Group again to build our array.
    {
        "$group": {
            "_id": null,
            "true": {"$addToSet": "$true"},
            "false": {"$addToSet": "$false"}
        }
    },

    // Once again project out just the fields we need
    {
        "$project": {
            "true": 1,
            "false": 1,
            "_id": 0
        }
    }
])

Here are the returned results in MongoDB 2.2.x - 2.4.x:

{
    "result" : [
        {
            "true" : [
                {
                    "endDt" : ISODate("2014-04-10T06:00:00Z"),
                    "active" : true
                },
                {
                    "endDt" : ISODate("2014-07-10T06:00:00Z"),
                    "active" : true
                },
                {
                    "endDt" : ISODate("2014-09-10T06:00:00Z"),
                    "active" : true
                }
            ],
            "false" : [
                {
                    "endDt" : ISODate("2014-02-20T07:00:00Z"),
                    "active" : false
                },
                {
                    "endDt" : ISODate("2014-03-10T06:00:00Z"),
                    "active" : false
                },
                {
                    "endDt" : ISODate("2014-03-30T06:00:00Z"),
                    "active" : false
                },
                {
                    "endDt" : ISODate("2014-11-30T07:00:00Z"),
                    "active" : false
                },
                {
                    "endDt" : ISODate("2014-12-30T07:00:00Z"),
                    "active" : false
                }
            ]
        }
    ],
    "ok" : 1
}

And in the soon to be released version 2.6.0, the results look like the following:

{
    "true" : [
        {
            "endDt" : ISODate("2014-04-10T06:00:00Z"),
            "active" : true
        },
        {
            "endDt" : ISODate("2014-07-10T06:00:00Z"),
            "active" : true
        },
        {
            "endDt" : ISODate("2014-09-10T06:00:00Z"),
            "active" : true
        }
    ],
    "false" : [
        {
            "endDt" : ISODate("2014-02-20T07:00:00Z"),
            "active" : false
        },
        {
            "endDt" : ISODate("2014-03-10T06:00:00Z"),
            "active" : false
        },
        {
            "endDt" : ISODate("2014-03-30T06:00:00Z"),
            "active" : false
        },
        {
            "endDt" : ISODate("2014-11-30T07:00:00Z"),
            "active" : false
        },
        {
            "endDt" : ISODate("2014-12-30T07:00:00Z"),
            "active" : false
        }
    ]
}