Some things I was aiming for:

1. Set them up with normal migrations.
2. Test them with the normal test suite/normal fixtures.
3. Make recovery/reset simple for when the table (inevitably) is somehow out of sync.

The “frequent counts” table

I’ll have multiple counts but not TOO many — enough that I don’t want to have a column per count but not enough that I mind using “LIKE” to lookup patterns, so my table has: id, code, current_count.

Code will be a unique key (important later) and be formatted like “style_ABC_size_456″.

So, when a new item is added it’ll be associated with a style and some sizes – each combination will either need to be setup (with a current_count = 1) or an existing combo will be found and +=1.

The FrequentCount class has the fairly straightforward finders that you’d expect + methods to reset each of the counts that it contains.  The reset methods follow the pattern “reset_frequent_count_COUNT_NAME” -> they clear the existing counts that they maintain before repopulating them.

I also threw in a reset_all method that looks for anything on the class following the “reset_frequent_count_COUNT_NAME” pattern and runs them.

The trigger-SQL

The SQL for creating the triggers will be needed by the migration as well as the test suite.  In fact, the test suite will need to run them somewhat often due to the way the standard tests ”prepare” the database.

I ended up throwing it in lib/trigger_sql.rb.  Methods there are named with the pattern “sql_for_TABLE_OPERATION_TRIGGER_NAME” ex: sql_for_items_insert_style_and_size

create trigger items_insert_style_and_size after insert on items
for each row
begin
insert into frequent_counts(code, current_count)
values (concat(‘style_’, new.style, ‘_size_’, new.size), 1)
on duplicate key update current_count = current_count + 1;
end;

# find methods that follow our pattern of “methods providing trigger sql” and execute the contents of each

TriggerSql.methods.select{ |m| m =~ /sql_for_.+/ }.each do |method_name|

ActiveRecord::Base.connection.execute(TriggerSql.send(method_name))

end

Night one went something like this:

I got an invite (did they do invites?) to checkout Heroku really early on.  At the time, I remember devoting a night to it – working with an online editor (or maybe I was ssh’d in with vi or something?) and basically just getting a little “Hello World” up and running.  Ever since bumping into Jim Fiorato’s app/case study the other day, I’ve been meaning to revisit a bit.

It’s entirely likely that the friend’s site will actually not need anything but static HTML, but hey: I can always tune the caching and free hosting can’t be argued with, right?

So, I opened an account out at herku.com and grabbed the heroku gem; installed git (officially taking me off the short list of people that still hadn’t given it a chance) and set to work on getting my app out there.

I hadn’t written anything, so I was just wanting to throw the “welcome to Rails” app out there to make sure everything was setup correctly.  The first bump was some fun with SSH keys.  I’m actually still not sure exactly what the issue was but there seemed to be some commands that were respecting the path to the key that I had setup but some others that seemed to be looking in the default location (~/.ssh).  I am actually thinking now that I probably could have got around it with a little more effort put into the config but I ended up just using the default key location — no probs after that.

At that point + some very simple/standard Rails app config, it was incredibly early to push the app out there, setup a few tables (via migrations) and get to work.

A little effort into a pretty basic layout and we’re underway.  It’s nothing spectacular to checkout at the moment – generic copy, placeholder colors/blocks and text… but someday it’ll be a star.

Need a hint?  The symptom was the +notes+ field being unexpectedly changed.

+display_value+ is pointed at +notes+. “<<” then goes ahead and changes that value (which both attributes are pointed at), thus both are effectively changed.

So, while it’s nice to avoid the extra String creation with “<<” where possible – sometimes, you’ve just gotta go with the “+=” to clone, then modify.


a and b ending up the same:
>> a = "a"
=> "a"
>> b = a
=> "a"
>> b << "asomething"
>> a.object_id == b.object_id
=> true



and different:
>> a = "a"
=> "a"
>> b = a
=> "a"
>> b += "something"
=> "asomething"
>> a.object_id == b.object_id
=> false


Partial Updates

Unfortunately, one of the things I’ve been looking forward to completely falls flat in my book… Partial Updates (to some extent: Dirty Objects).  

When I first read the paragraph-blurb about this addition I was pretty impressed and was looking forward to seeing how it was implemented.  I was much less impressed when I got my head under the hood.  Relying totally on use of ActiveRecord setter methods is a pretty big fail in my book.  Tracking down every place that a field is edited “in place” to specially flag it (xyz_will_change) is completely unreasonable and maintaining that rule going forward is an annoyance that I just don’t need.

I played with several ways of attempting to set flags when changes were “likely” (ex: when getters were used) or always flagging “likely to be edited in place” attributes (ex: serialized fields) but just was ending up with lots of additional complexity, reduced reliability, and basically voiding out any gained efficiency.

Having this enabled by default (apparently the plan) is just plain confusing:  Seems much more reasonable to enabled this when you know it’s going to benefit you.  I also don’t like that it adds another question for a new developer to ask (or get tripped up on) when joining a project.  I really don’t want to have to read every line of the new guys code for the first three months to make sure that he’s sticking to the rules (and setting up tests to verify it explicitly).

XML handling

Null values are now flagged as such instead of just being blank, like they would look if they were… uh… blank.  This is a good thing – it also tripped me up for a bit.

Eager Loading

It seems eager loading has been changed a bit.  Statements that used to result in :include items being joined right into a single large query now (may) result in several smaller statements.  

Does it make queries more efficient?  Probably.

Does it increase db traffic?  Probably.

Is it a bad thing?  Probably Not (overall).

Is it a bad thing that stuff that worked before doesn’t?  Yeah, that’s annoying.

My specific problem is on an association defined with a :select => “distinct labels.*”.  I played around a bit with potential changes down in the AR guts but in the end (unfortunately) I ended up basically tricking it into running it as a single statement.  It’s not at all difficult to make it happen but it’s also not at all straightforward – and I hate it when the framework makes me write a big comment.

For me, I added an rder to my find that would make it order by something in a different table, which scares the thing into running a single statement.  Ideally, I’d like to have something explicit (maybe on the association but more likely on the find itself) that would allow an optional param to say “run this as one statement”.  That would let someone reading the code clearly see what’s going on – instead of wondering (or more likely: not noticing) that I’m ordering by some pointless field.

Overall

Not nearly as bad as I had expected.  Felt good to get some deprecated stuff fixed and get some of my old TODOs out of there in the process.  Also good to have it (almost) over with and to, at least temporarily,have caught up with the Joneses.

You want to know how many Items are currently in the Store and you’ve got this in your Store definition:
has_many :items

If the Items for this Store have already been read in and objects have been mapped, you simply want to ask for the count:
flagship_store.items.size

but if they haven’t already been mapped, you want to just do a quick select count(*):
Item.count(:conditions => ["store_id = ?", flagship_store.id])

The answer?

For many of us it’s:

item_count = flagship_store.instance_variable_get(:@items) ? @items.size : Item.count(:conditions => ["store_id = ?", flagship_store.id])


And for those of you living in the future it’s even more straightforward:

item_count = flagship_store.instance_variable_defined?(:@items) ? @items.size : Item.count(:conditions => ["store_id = ?", flagship_store.id])


store[manager] = Bob Smith
store[location][state] = Wisconsin
store[location][zip] = 53590

And easily process them on the server side with something like:
Store.new(params[:store])

So, why does this:
link_to “Store”, :controller => :store, :action => :show, :store => { :manager => “Bob Smith”, :location => { :state => “Wisconsin”, :zip => 53590 } }

output something stupid like this:

http://localhost:3000/case/1/store/show?store=locationstateWisconsinzip53590managerBob+Smith

when what I’d like is something like:

http://localhost:3000/store/show?store%5Blocation%5D%5Bstate%5D=Wisconsin&store%5Blocation%5D%5Bzip%5D=53590&store%5Bmanager%5D=Bob+Smith

Well, without further ado, I give you the url_for hack to make it happen (note: For a widespread solution this would need to do a bit more… escape things, handle some different object types, handle more than 1 layer of hashed values, etc… but you get the idea)

Putting this in url_for has other benefits since lots of things depend on it. For example, now you can do:

redirect_to :action => :show, :store => { :manager => “Bob Smith”, :location => { :state => “Wisconsin”, :zip => 53590 } }

This is especially handy if you’d like an action to “hand off” some of the params that it’s received via a redirect.

After a bit of digging the issue ended up being that:

<a href=”http://seekingalpha.com”>SA</a>

displayed like this (which is desired on the unit):

SA <http://seekingalpha.com>

While this:

<a href=’http://seekingalpha.com’>SA</a>

displayed:

SA

Not sure if ignoring links with single quotes is something on all Blackberries – just this unit – or even the way this particular unit is configured… but at least it’s not hard to fix once identified!

A nice and simple testing recipe (#68) demonstrates how to read in an email from a fixture in just a few lines and pass them to your processing method (MailReceiver.receive in this case).

def read_fixture(action)
IO.readlines(“#{FIXTURES_PATH}/mail_receiver/#{action}”)
end

def test_something
email = read_fixture(“junk_mail”).join
MailReceiver.receive(email)
# assertions
end

And then a few lines on how to feed it “for real”. and we’re up and running!

The only catch… there was some anger over the parens:

mailman: "|/path/to/app/script/runner Mailman.receive(STDIN.read)"

We ended up escaping them, but according to those directions I just linked to – you can also just quote the call to receive.

I just need to make sure that a user has at least one record:

assert_not_equal 0, UserPreference.find_by_user_id(user_id)

As you may have just caught: that is always going to pass. Not a tough mistake when you’re motoring along and not putting too much thought into something so simple: The finder isn’t going to return the count of matching rows… it’s either going to return a populated object or nil, neither of which will be equal to 0.

Fixing the bug is trivial, but lesson learned:

From now on whenever I write assert_not_equal – I am going to make sure it works by temporarily changing it to assert_equal and taking a look at the error message.

In this case: if the error message said something like “<0> expected but was <2>”, I would know that things are working.

Whereas if the error said “<0> expected but was <#<UserPreference…>>”, I’d know right away that I need to fix it up (and have one more cup of coffee).

After doing quite a bit of searching for the simple way, I really didn’t turn up too much. Finally, I decided I would just open the file and write it out the old fashioned way: using the File object.

Got that all done, but for some reason my content-type in the header wasn’t getting properly picked up so the receiving browser was thinking it was something to save to my desktop. A quick look to make sure that my syntax was correct and there it was…

send_file(path, options={})

So, yeah. To have your controller send an image back:

send_file ‘/the/path/image.png’

Pretty tough