This dump is odd: CCP is using integers where they mean to use booleans. So in those cases remember 1 is true, 0 is false. Good luck.

Edit: As a note the Eve Online Database Viewer is updated with this dump.

Edit 2 (July 31, 2008): I nearly forgot to give props to bunjiboys for providing the .sql files from which the above dump is derrived.

So I’ll post the patch here so it’ll get a bit more visibility and hopefully Oracle users can find it helpful in speeding up rake db:migrate on Oracle systems with a lot of indicies.

Patch to speed up Rails’s OracleAdapter#indexes method

Included in the zip archive is a Schema file as well as each individual table as a .sql file. They’re numbered 001 to 065. 001 is the schema (001_schema.sql) and is intended to be imported first. The others have no real order as there are no foreign key constraints but were numbered for my testing and sanity.

View the dump online

A lot of cool things can be done with after_initialize, especially if one uses the database as a means to store meta-data about a model. Use the after_initialize method to transform your models with Ruby after they're fethced from the database. Consider the following User model definition:

It's pretty clear that with the :group => "group_id" that I want a unique set of Membership objects. That works well when I've already got a User and do user.memberships but not at all when I do User.find(:first, :include => :memberships); likely because of the way the join is set up and grouping on that may not be possible.

I still wanted to use eager loading so I thought that it would be an OK sacrifice to fetch all the Membership objects even if I wanted to pare it down after I initialize the User object (with eager loading). I defined:

Except it doesn't work. Quickly I found the following from active_record/base.rb (click link for source): right where it does the after_initialize callback! But it wasn't working for me. I needed to dig further.

Further research indicated that before the creation of the @memberships instance variable that would hold the collection of Membership objects the after_initialize callback was being fired off in the User model. Using after_initialize would not work due to the design of ActiveRecord. I'm still searching for an elegant way to work the way I want. I'll post again when I find it!

I rewrote my Eve Online Database Viewer. With the recent Trinity Dump (Postgres version coming soon) I wanted to rewrite the PHP script in order to better make use of mod_rewrite and to better handle errors.

I hope it's accepted. Incidentally, it works and has saved me a lot of time with migrations.

Edit: Yeah, turns out that since turning these adapters into gems patches for them shouldn't be done through Rails trac. How irritating, but whatever. I've sent the patch do the current maintainer for review.

I hope it's useful for everyone.

One of our clients from work uses Beast forum. Unfortunately last week it kind of died. Mongrel's logs were complaining that it couldn't allocate memory, the index (ForumsController#index) was taking upwards of 12 seconds to load...

The problem was SQL. Beast is very greedy when it displays the front page; it does a forums.posts.last.created_at to get the timestamp for when the last post was made. This is done for every top-level forum and it will destroy your site.

At about 21:30ish the previous night I disabled the site because my brain was mush and I couldn't focus enough to diagnose the problem to say nothing of finding a solution. The next day when I got to the office I spent the first 90 minutes of the day diagnosing and fixing the problem. I found that I could find the relevant data with a GROUP BY and ORDER BY with one query for all forums... Except the times were the FIRST post and not the LAST post.

So I spent the next two hours figuring out why MySQL didn't want to ORDER BY and formulating a query that was both quick, returned data for every forum and worked. This is the ugly thing that resulted:

This is fed into:

In the view we just substitute forum.posts.last with @last_posts[forum.id].first in all instances. This may have to bet tweaked for your setup because I'm not sure where Beast ends and client-specific stuff begins.

You see there's some parent_id things going on in the SQL. At work we made Beast forum nested. We do plan to make these changes available for others to use but it's just a matter of finding time to get rid of the client-specific modifications and merging to trunk.

This is one of the things that I'm proud about: the SQL query was a pain!

For me I find it easier to use the console because it reinforces the ORM - an entry in the table is just an instance of a class that models that table. I find that Constellation.find(:all, :conditions => "faction_id = 0").each { |c| c.faction_id = nil ; c.save! } is more meaningful (and easier) than sorting by the value of that column and mass updating. Icky

When I need to construct weird SQL queries, however, I'll drop to the mysql or psql shells. GUIs are icky and their bulky interfaces tend to slow complex queries down. Of course, I'm a console geek so I'm slightly biased here.

Anyways, I cringe a little when I see people opening SQL GUIs to find table structure or to find data values and to change single values. But hey, different strokes for different folks!

What this eventually boiled down to is Rails fixtures MUST have an id attribute on them or you may run into errors! This was hidden behind the scenes since heretofore we were using auto_incrementing MySQL fields. To get this behaviour in Oracle one must do

(done by Rails automatically, normally) or set up a Trigger (not done by rails, and would have to be done in a create_table migration).

However, fixtures bypass the normal ActiveRecord::Base#create call and just does a raw execute insert into... Which means there's no value for id, unless it's specified in the fixture. This kept me at it for hours today and I only found it by hacking the fixtures source to make it print in the logs what it was doing!

Let this be a lesson! Always put in ids even if you don't care about their values.