<%= NewRelic::Agent.browser_timing_header rescue "" %>

David van Geest

Software, Life, and Stuff I Couldn't Find on the Internet

Hacking session maintenance with Authlogic and Factory Girl

| Comments

I use Authlogic to provide authentication for a couple Rails projects. I also use Factory Girl as a fixtures replacement.

When FG creates a User for you, a new UserSession automatically gets created. This is by virtue of Authlogic’s automatic session maintenance, which can be pretty handy. However, in my tests I want complete control over the UserSession. Just because I created a new user, doesn’t mean I want that user logged in. In many cases, I don’t want the user to be logged in, and this behavior was causing my tests to fail.

To work around this behaviour, I ended up adding this to my User factory:

1
2
3
after_create do |u|
  u.class.maintain_sessions = false
end

That quashed the autogenerated UserSession. There might be a cleaner method somewhere, but so far this is doing the trick for me.

Excluding all attributes in options for to_json

| Comments

Ran across a strange gotcha while working in Rails 3.0 today, having to do with the :only option to the to_json method.

Let’s say you have a Widget on which you call to_json. You don’t want any of the widget’s attributes to appear in the JSON (maybe you only want some method results). Normally, one would expect this to do the trick:

1
{:only => [], :methods => [:foo, :bar]}

Strangely, this didn’t work. I found I needed to put a nil in the empty :only array, like so:

1
{:only => [nil], :methods => [:foo, :bar]}

for everything to work as expected.

This might have something to do with the fact that I’m using the json gem, but I haven’t had the time to dive into that.

Disabling the query cache and profiling MySQL

| Comments

I’m constantly forgetting how to enable profiling and turn off query caching in MySQL. So for my own benefit, and possibly yours, here’s the goods.

Turn off the query cache for your particular connection:

1
SET SESSION query_cache_type = OFF;

Enable profiling for your connection:

1
SET profiling=1;

Run the query:

1
SELECT * FROM widgets WHERE plant_id = 5 ORDER BY widget_id DESC LIMIT 1;

Show the profile:

1
SHOW profile;

You’ll get something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000087 |
| checking permissions | 0.000013 |
| Opening tables       | 0.000106 |
| System lock          | 0.000099 |
| init                 | 0.000036 |
| optimizing           | 0.000019 |
| statistics           | 0.000311 |
| preparing            | 0.000027 |
| executing            | 0.000006 |
| Sorting result       | 0.000006 |
| Sending data         | 0.001665 |
| end                  | 0.000011 |
| query end            | 0.000008 |
| closing tables       | 0.000023 |
| freeing items        | 0.000034 |
| logging slow query   | 0.000005 |
| cleaning up          | 0.000006 |
+----------------------+----------+
17 rows in set (0.00 sec)

Remember that the time in the right column actually corresponds to to the operation in the row ABOVE. So in this case, the operation that took 0.001665 seconds was the Sorting result operation, not the Sending data operation.