One of the really cool, well designed features in MongoDB is the aggregation framework. Basically it is the feature that brings MongoDB query language on par with SQL in feature richness. Most importantly, it fully supports sharding for scale-out and parallel processing. I've had a lot of fun with it.

Last night I accidentally came up with a fun exercise that you can solve with a nice aggregation framework pipeline. I'll present it as a challenge, feel free to suggest answers in comments. I'll share my answer next week.

Suppose you work in a flag factory, and you have received the following orders:

> db.flags.find().pretty()
{
	"_id" : ObjectId("52a7189ecd4dd732cd060201"),
	"country" : "Finland",

Last week I was assigned to work on a simple yet interesting problem. MongoDB stores data as JSON. But it turns out we often have customers - especially in the important financial services market segment - where data is in XML. (Yes, SOAP still exists too!) To store that data into MongoDB, we need to transform it into JSON.

(For the impatient reader: here's the Github link!)

Storing XML as a text field

There are various ways one could do this. For example one could simply store the XML document as a whole in a single field, and then extract just a few parts of the XML that are stored as individual JSON keys. One reason to do this is that they can then be indexed and used in queries.

For example:

Monday, Aug 26 will be an exciting day if you live around Stockholm and are interested in MongoDB, Node.js or just open source and web programming or anything in this direction.

In the morning, from 9:00 to 12:00 I will be doing MongoDB office hours. This is an "ask the expert(s)" type of free community consulting thing we do regularly at 10gen. You can come and discuss your MongoDB application, architecture or just basic questions. First come, first served. Please RSVP at https://www.meetup.com/Stockholm-MongoDB-User-Group/events/134695732/

Oscon is over, I'm home and recovered both from jet lag and just general exhaustion.

Oscon is a very broad conference so there is a lot to learn and many people and projects to befriend. There are many things and angles one could write a blog post about. To me Oscon is above all the conference to meet other open source people and have the deep and inspiring discussions. So in that spirit I will make a few philosophical remarks in this post, thoughts from Oscon 2013.

If you'd want to read a run-through of the conference itself, I recommend Dirk van den Poel's very extensive summary.

One of my favorite MySQL tools ever is pt-query-digest. It's the tool you use to generate a report of your slow query log (or some other supported sources), and is similar to for example the Query Analyzer in MySQL Enterprise Monitor. Especially in the kind of job I am, where I often just land out of nowhere on a server at the customer site, and need to quickly get an overview of what is going on, this tool is always the first one I run. I will show some examples below.

5 years of MySQL

People often write a blog post when they reach some nice anniversary since they joined MySQL community. Well, for those old enough it usually means when they joined MySQL AB as employee. For me this was January 2008. Because I didn't remember the month correctly, I haven't blogged anything then, but decided to save it for a better opportunity - now.

TL;DR Starting this week I will be working for 10gen, selling MongoDB to the Nordics. This blog post is really long - even then it doesn't contain the most interesting stories, I'm not sure if they can ever be published. Sorry for the length, but remember you don't need to read all at once. This is my last MySQL post so save some of it for cold winter days!

2008 - Sun acquisition

One of the greatest things with working in the MySQL community has been to meet so many people and travel in different countries and cultures. In my last blog post I mentioned how I learned that in Southern Europe it is considered offensive to go too early to meet your customer. As the customer is expecting you to come later than agreed (everyone always does), if you show up too early you are taking away time that he was expecting to still use to prepare for the meeting.