Still Learning, Part Two
Posted 2007 Feb 01So the problem I wrote about in Part One involved passing the organization_id of the current_user into just about every Model method. I quickly set off looking for the most complex solution: filters, overriding the base find_ methods, meta-programming, monkey-patching, you name it!
Well, too bad the answer was staring me right in the face: make the calls to each model relative to the current_user! There’s a reason :has_one, :has_many and :belongs_to exist!
So, instead of writing:
Attendance.find_by_organization_id_and_room(
current_user.organization_id, room)
I should write:
current_user.organization.attendances.find_by_room(room)
Now, that doesn’t seem like a big difference, but it saves me from having either add a “by_organization_id_and” to every find method or adding some “with_organization_scope” code. It also feels more like Rails.
I have one concern, though. The call to “current_user.organization.” will result in a database call versus just passing “current_user.organization_id”. While this doesn’t seem like a big deal, it seems a little unnecessary. Since the current user’s organization won’t change—I should be able to cache it.
Update: /sigh. I shoulda known. This was covered on a recent Rails Way post.