PMOG will be down for maintenance on Thursday, 31 January, midnight California time. We should be back up some time after that! Just a few hours, we think, from where we sit, before the maintenance starts.
Our preliminary run for PMOG is now surpassed 100 users!
![]() Staring into a Portal on PMOG |
We’re so excited to be playing this game again with people. We’ve been hatching these ideas for almost two years now. We took the last few months to prepare a version of PMOG more deeply integrated with surfing, and more richly illustrated. Hopefully it should be something pleasant to look at or ignore while you are surfing
all the while earning datapoints and having a wee bit of social adventure across the weird wild and wonderful world wide web!
We’re inviting folks every other day, so if you haven’t signed up for the beta, please visit http://pmog.com/ and put your name down
As all good Ruby on Rails programmers know, there are plenty of plugins out there to help you get on with creating your application. Not having to re-invent the wheel for things like tags and pagination can be a huge blessing.
There are also a great deal of plugins that attempt to give developers an idea of how hard Rails is working the database. Plugins like qtrace, query_stats, query_trace and query_analyzer all exist to serve this purpose.
In my experience, though, no one plugin does everything I need. I don’t mind installing each of those listed above, though, as it feels like a very discreet and unix-like mindset. Do one thing and do it well.
To that end, here’s my addition to the array of sql-surveillance-plugins, called Sql Profiler. Here’s how I described it in the README:
SqlProfiler just logs the queries your application makes so that you can pull out a report of the most executed ones, making it a pretty dumb but quick way of profiling your code and finding the initial places to start caching. It also logs the number of rows returned by each query, which is handy for finding memory leaks, as I discovered recently when a custom finder I’d thought was intelligent (as it made extensive use of :include to fetch in all the required associations) turned out to be lacking a simple ‘group by’ statement, resulting in thousands upon thousands of rows being returned.
Get it here – http://rubyforge.org/projects/suttree/ – or install it directly into your application like so:
script/plugin install http://suttree.rubyforge.org/svn/sql_profiler/
Feedback, bugs, suggestions – they’re all welcome!
With a helpful nudge from Artur, we’ve been using UUID primary keys on almost all of our Rails models to ward off scalability problems further down the line (see this for a decent guide to how and why).
In general, Rails copes with it all extremely well. As you’d expect, Rails handles standard MySQL primary keys without any intervention, but if you want to use UUID keys it offers you enough callbacks to do so. There is one such instance where we had problems, though, where one of our models is using acts_as_list along with acts_as_tree.
With a standard ‘acts_as_list :scope => :parent_id’ declaration, Rails has some trouble parsing a UUID key when it expects a standard integer one. Like this:
Mysql::Error: Unknown column ‘9dd631cc’ in ‘where clause’: SELECT * FROM branches WHERE (parent_id = 9dd631cc-5ac3-11dc-b5f5-0017f232d58f) ORDER BY position DESC LIMIT 1
Which, as you can see, is caused by improper quoting of the ‘parent_id‘ field. UUIDs are strings, and Rails is parsing it as an integer. Digging into the guts of ‘acts_as_list’ shows us that the relevant conditions are created by a method called ’scope_condition’ which is setup with a class_eval. Before you go digging any further, though, the API docs helpfully point us back to the ‘acts_as_list :scope‘ arrangement. Although ‘acts_as_list :scope‘ expects a symbol from which to create the ’scope_condition’ method, we can pass in a string, and have Rails take care of the quoting, like so:
acts_as_list :scope => “parent_id”
Now everything is quoted properly, and the tree structure happily accepts UUID primary keys! As you might expect, my reaction to this was, simply, ‘awsm’.
Nb, db/schema.rb also has some problems with UUID primary keys, ignoring them, in fact. So, use ‘rake db:test:clone_structure‘ to setup your test database properly.






