For the past year+ I’ve been doing client work for Tom Locke’s Artisan
Technology web development consulting
firm.

The app I’ve been working on allows a user to perform various standard business
intelligence queries on a dataset using a pretty cool AJAX front-end.

We’re using MultiDimensional eXpression Language (MDX) to write our BI queries
in. We then execute the queries against our database engine using the
excellent and open source
Mondrian project.

When I was originally handed the project, all queries were built using
super general MDX snippets with several “REPLACE_ME_WITH_DATE_CLAUSE” tokens
that would get replaced or removed as needed for a particular query.

Also, once we executed a query against the database using Mondrian, the
results obviously came back as Mondrian (Java) objects with all the lovely
readability that that language is known for. Getting to the actual data in the
mondrian results turned out to be something like:

1
2
3
4
5
6
7

# to get the column headers
column_headers mondrian_result.get_axes(0).get_positions.map &:get_caption

# to get the row headers
row_header     mondrian_result.get_axes(1).get_positions.map &:get_caption

# getting at the actual grid values will make your eyes bleed so it is omitted

Even then, you couldn’t refactor this very cleanly as not all queries returned
rows, so get_axes(1) would throw errors and gah! it was really messy!

This was not fun. I spent a couple of days trying to figure out a.)
what the hell is this MDX thing and what’s it do? and b.) how am I going to
figure out what text snippets go where and what placeholder needs to get
gsub’ed (or was that just sub?) with what other snippet.

Then I approached Tom with a pretty radical idea: give me a while and I’ll rip out all this text
manipulation stuff and replace all MDX strings with calls to ruby objects.

Tom, being damn awesome, answered exactly as you would hope!

So `git checkout -b heaven` and boom! I started hacking about. I had a rough
idea of what I wanted…

1. I don’t want to write MDX in my classes
2. A quagmire of a java object is not ‘results’, I want ruby objects that make
3. sense.

The first version was called MDXBuilder, a utility class that provided a
pretty basic DSL for writing MDX queries and returned a simple hash with
values for rows, columns and grid. This was already a big improvement. So much
so, in fact, that I later did a complete rewrite that allowed you to define
your entire mondrian schema using ruby classes, then run a rake task to
generate your mondrian datamart definition XML (which sucks doing by hand,
trust me.) Think an ‘ORM’-like abstraction for business intelligence queries using
Mondrian. (ORM isn’t quite the right pattern though as BI queries don’t return
objects, but rather result sets.)

Anyway, I wrote it as a plugin and we’ve been using it and steadily improving it for
months now and every day I get happier and happier using it.

However, the fact that it’s a plugin has always gnawed at me. It needs to be
a gem. Also, I currently use inheritance on classes:

1
2
3

class SalesDimension < MDSL::Dimension
  ...
end

But since I saw the newer ruby ORMs move to mixins I’ve been in love with the
idea…it makes so much more sense.

So my next task is to:

1. Turn MDSL plugin into a gem
2. Use include MDSL::SomeClass instead of inheriting from it

I hope to find time to work on this soon, so follow along if you’re
interested. For the next few posts I’ll be looking at cool patterns that I
find in some of the existing gems that do things I’d like to copy in mine.