Having the conference behind now, I'm reviewing some of my impressions and of sessions I attended.
To begin with, this conference was a big success for me, in many respects. The sessions were great (more on that later), but of course, meeting with new people and with familiar people, was the more important part.
I live in Israel, which makes travel to the US very long and expensive. Apparently not many MySQL community members in my neighborhood, so I don't ever get to meet the faces. The conference makes that possible. I did not participate in all community events, as I had scheduled calls with little girls who miss their father. And I was very much under jet lag. And I have more excuses on demand.
But I did get to meet known faces; people I only knew by name; unfamiliar people who were familiar with my work (fun!); and otherwise just (ex-)strangers.
There was a variety of sessions to choose from. Many times, I had to pick one out of two or three sessions I was interested in, running at the same time. Not all sessions appeal to one in the same way, but looking back, I find there were a lot of GOOD sessions I attended. I mostly like sessions that are very technical; preferably drilling into details of algorithms & implementation.
I wish to review some of the sessions I attended. I can't possibly review them all, so my apologies to those I left out.
- Learn how to cure MySQL replication deprivation with Tungsten! / Robert Hodges (Continuent.com), Edward Archibald (Continuent)
This is actually the first time I learned about the internal details of Tungsten. Robert, CEO of Continuent & original developer of Tungsten, did an excellent job in reviewing the various aspects of Tungsten. But rather than being a promotional talk, this was a purely technical tutorial.
So it was interesting to understand the difficulties in building Tungsten, at least on the MySQL part. For example, the Tungsten replicator must do its own filtering of events based on server id, since, although a replicating slave knows how to ignore circular queries issues by itself, there is no client API to do so; you can't "send over" the server id along with a query and expect the server to ignore it.
As seems to be the current and emerging paradigm, parallel replication is possible by paralleling queries from different schemata. But apparently Continuent seem to want to change that. That is, there's nothing that strictly forces that this must be the paradigm; it's just the current implementation.
Giuseppe was in charge of live demos, and has shown stuff like slave disconnect, fail over, multi-master replication etc. Edward Archibald later presented a cluster-like solution based on Tungsten and a replication aware connection proxy.
There was plenty of time for asking questions. Interesting technical issues were discussed and answered. It was also stated very clearly what Tungsten does not do for you, or when it may actually be the gun with which you shoot yourself in the foot. Good talk!
- MQL-to-SQL: a JSON-based Puery Language for RDBMS Access from AJAX Applications / Roland Bouman (XCDSQL Solutions / Strukton Rail)
Roland is now passionate about finding an easier query language for web applications to use. Rather than SQL, he suggests using MQL (created by Freebase). MQL uses JSON (-like) syntax to describe both queries (requests) and result sets (responses). I won't go into the details since Roland himself laid them out on his blog.
As usual with Roland, his session is well thought of. He describes an elegant, appealing syntax. In my opinion, MQL is an intuitive language. It is easily comprehensible by both DBAs and developers. Possibly by my mother.
However Roland goes further and offers his MQL-to-SQL, an open source implementation of a translation tool between the two languages. In his presentation, he demonstrated some simple and some not-so-simple queries, generated by MSQL, translated to SQL, the results of which translated back to MQL.
MQL is not an all-purpose solution. You don't do analytics with MQL, but it does seem to answer some problems that other ORMs (e.g. Django) are, to the best of my knowledge, unable to perform in convenient manner (that is, without reverting to some SQL-like syntax).
To be continued
I need to prepare for my flight. Will probably publish next part(s) once back home. Hope to see you all next year!