I’ve been working with a client to optimize parts of their Rails application. The problem is that a method in the app does some simple updating of a few model objects but because the model has so many relations it goes through a ton of unnecessary callbacks. There are issues related to data concurrency which means you have to do the callbacks but in this particular situation there won’t be any concurrent updates to the data so the callbacks can be omitted. The solution to the problem was trivial when using the save_without_callbacks Rails plugin. Just adding a simple:

before the update_attribute reduced the number of SQL UPDATE queries from 90 to 8. Lesson learned. If you need to skip model relation callbacks on save this plugin is for you. Be careful about data concurrency issues though.

Its been a long time coming but we’ve finally got our new site design finished for Onomojo. We’ve also expanded our services to include graphics design, logo design, web design, and a whole slew of other graphics related services. That’s in addition to the services we already provided which were primarily programming, seo, and marketing related. Here’s a screenshot of the new design.

I’ve been searching for a free uml diagramming tool for Linux for a long time. There are plenty of options but nothing really stable or good enough for what I need it for. I stumbled on Gliffy today. Its an online diagramming tool written in Flash. Best of all you can use it free given some minor limitations. I tried it out and its exactly what I’ve been looking for to help collaboration between remote developers. I definitely suggest you check it out.

In my previous post I wrote about trying to get class table inheritance working in Rails. I passed by the hack and went with the plugin which ended up not really working right. I revisited the class table inheritance hack and actually got it working. I pretty much just dumped that code into a plugin so all you have to do is:

spaghetti.rb

noodle.rb

One thing that did trip me up at first was that the spaghettis table can’t have an ‘id’ column for a primary key or you end up with some strange stack overflow errors. The noodles table also needs a ‘type’ varchar column to store the class names of the rows its storing. Even pagination works when you explicitly state what tables you’re conditions are using as in:

Download the class_table_inheritance plugin

I have a Rails project I’m working on that seems to be best suited for class table inheritance. Conceptually it will greatly simplify the database and reduce tons of code. There will be a performance hit due to the extra joins. I think that will be manageable though and the simplification of the entire site architecture will make it well worth it. The problem is that class table inheritance isn’t currently implemented in Ruby on Rails and requires a hack to make it work. I’m weary about implementing this hack mostly for long term maintainability since its such a crucial aspect of the site’s architecture. Ideally, class table inheritance will eventually be built into the Rails core but who knows when that’ll happen.

Then I found the inherits_from plugin which made me a bit more comfortable so I tried it out. It works in a very primitive way so long as I’m not using any conditions in my find commands. For instance if I had a product that stored a name and a car table which is going to inherit everything from the products table:

car.name works fine and it would be great if that’s the only way I ever needed to use it. The problem is when I try to toss some conditions into the mix that are conditions against the parent model. So if my products table also had color and I wanted to do something like:

It doesn’t work because its not doing a join but rather 2 separate queries. 1 query for the car table to get the product_id and the other on the products table. Using:

Doesn’t work either. The solution? One option is to extend ‘find’ to make it recognize when its supposed to do a join instead of 2 queries. I’m not looking forward to hacking that mess up cause it opens a big can of worms. For example, how would it handle pagination with conditions as well? I’m not using the plugin. After my getting to that point with the plugin I decided to take another look at the first hack I linked to and see how much effort it really is going to take to get this thing working. I might just end up scrapping class table inheritance altogether and accept the big messy database structure and code redundancy that will ensue.

Anyone in their right mind who is running a mission critical database is already doing daily backups of the database. Its not often feasible to backup the entire database more than that. Without a proper plan, you’re stuck with a possible 24 hour data loss in the event the server dies just prior to its next backup. All transactions throughout the day are lost.

Luckily you can configure MySQL to store binary logs of all transactions that modify data in the database. These logs are typically going to be much smaller than your entire database so you can simply back them up more frequently than your entire database backup. When recovering from a system failure you would simply first restore from a nightly backup. Then restore from your binary log backups to ultimately reduce your data loss to whatever interval your binary log backups are set to.

To do all this you need to add the following lines to your my.cnf file:

log-bin = /var/log/mysql/.whatever
binlog-do-db=
expire_logs_days=2


I like to store 2 days of binary logs just in case something is screwed up I have 2 days worth of transactions I can potentially restore from. When restoring you need to be careful not to repeat transactions from prior to your nightly backup. So, if your nightly backup was exactly at midnight, you want to make sure you restore only the binary logs that occurred after midnight. Then you need to set a cron job to do the backup for something like every 5 minutes and you’re good to go.

I just spent the last few hours trying to figure out what was wrong with my new Wordpress plugin. My plugin requires another plugin and what was happening was Wordpress was running my plugin first. This was the source of the problem and it took me awhile to figure that out. Then I had to figure out how to force Wordpress to run my plugin first. I tried a code solution but there isn’t any way to tell Wordpress in the code to run one plugin before the other. Then I tried modifying their order in the database but Wordpress kept rewriting the row I would change. So then I thought, alphabetical ordering. I don’t want to have to rename my plugin just because of some stupid limitation of the Wordpress plugin architecture. I noticed that it was running the plugins that had their own subdirectories first and then it would execute plugins that were just single files inside the plugins directory. Bingo. I removed the directory I had put my plugin from and just dumped it right in the plugins directory. Now it works beautifully. It was troubling me because I already had the plugin working on another blog (before I made the subdirectory modification) and was scratching my head why it wasn’t working here. Its all simple in retrospect.