This will be a little bit backwards, since now I am going to talk about the first day of PG Open – the day of tutorials. I’ve signed up for both “advanced” tutorials. The first one was “Surviving Server Overload” by Greg Smith, and I didn’t like this one too much, mainly because he was talking about well-known things, but also because he didn’t time it rightly, and then he went way overtime, and still didn’t finish what he wanted.

But the second one was just great, it was an Introduction to SQLAlchemy and ORM by Mike Bayer. Those of you who are familiar with my research (and development :)) interests can imagine, that I could not possibly pass a tutorial with a title like this one.

So I came in among the first participants and made sure I am in the firs row, it he best possible position to see the screen. I was closely listening to the first part, especially since he mentioned his goal is not to hide the SQL from developers and make sure they continue to think in terms of database/SQL concepts. I was patiently waiting to see what he is doing in terms of overcoming the class-table mapping limitations, but this didn’t happen till the second part.

During the break I overheard Mike saying something to the effect of “that’s easy, this is not an object-relational impedance mismatch!”, which prompted me to jump in right away and ask: So, are you going to tell about ORIM in the second part of your tutorial?

Turned out – not in details, but effectively, the big part of the techniques he was talking about was avoiding ORIM. For example, if you look at this presentation, the Level 3 of the whole thing is “SQL Expressions”, which basically allow to embed efficient queries into the model. All the time as was listening to the tutorial I had a feeling that it something very near to what I am doing, but… not exactly. After the tutorial was over, I’ve asked him the most pressing question: how he can ensure application developers actually use all these options. And I’ve also told him, I would love to discuss with him what I am doing, and if he please come to my talk (which he did).

We had another long conversation after my presentation, and agreed that we would probably want to collaborate, if we figure out, how. The differences in mine and Mike’s point of view, as I understand it are primarily due to the fact, that I work with application developers, being a database person, while he is “all in one” combining both roles and both points of view. And how often we come across an application developer who know how to write efficient queries, and who can tell imperative from declarative?!

To recap: I find the SQLAlchemy approach incredibly interesting and promising, and I highly recommend everybody who is developing database applications and how is not constrained with the choice of preferred tools, to take a closer look at it. This is the part of SQLAlchemy philosophy, which I consider the most important:

SQLAlchemy considers the database to be a relational algebra engine, not just a collection of tables. Rows can be selected from not only tables but also joins and other select statements; any of these units can be composed into a larger structure. SQLAlchemy’s expression language builds on this concept from its core.