----------- SCAN SUMMARY -----------
Known viruses: 6288879
Engine version: 0.98.7
Scanned directories: 79272
Scanned files: 257567
Infected files: 14
Total errors: 18985
Data scanned: 4639.85 MB
Data read: 5473.88 MB (ratio 0.85:1)
Time: 692.947 sec (11 m 32 s)

/tmp/clamav
/tmp/clamav/maldetect-1.6.tar.gz.001
/tmp/clamav/rfxn.yara.002.001
/tmp/clamav/rfxn.yara.004.001
/tmp/clamav/rfxn.yara.001
/tmp/clamav/rfxn.yara.001.001
/tmp/clamav/rfxn.yara.003.001
/tmp/clamav/x86_64.h.001

rails@epic-invite-staging:~/apps/epic-invite/staging/current$ bundle exec pumactl -P tmp/pids/puma.pid restart
Command restart sent success

rails@snarf:/var/www/mini-epic/current$ sudo -u postgres createuser --interactive
Enter name of role to add: rails
Shall the new role be a superuser? (y/n) y
rails@snarf:/var/www/mini-epic/current$ RAILS_ENV=staging rake db:create
rails@snarf:/var/www/mini-epic/current$ psql epic_invite_staging < /tmp/mini-epic.pgsql

class Dave
  def monitor; end
end

Dave.method_defined?(:monitor)
 => true 
Dave.method_defined?(:iareweasel)
 => false

-- C level backtrace information -------------------------------------------
0   libruby.2.2.0.dylib                 0x0000000103e6e885 rb_vm_bugreport + 149
1   libruby.2.2.0.dylib                 0x0000000103d0dbb4 rb_bug + 468
2   libruby.2.2.0.dylib                 0x0000000103d0deac rb_bug_errno + 92
3   libruby.2.2.0.dylib                 0x0000000103e7cb2c thread_timer + 588
4   libsystem_pthread.dylib             0x00007fffbb4ac9af _pthread_body + 180
5   libsystem_pthread.dylib             0x00007fffbb4ac8fb _pthread_body + 0

-- Other runtime information -----------------------------------------------

* Loaded script: bin/rails

* Loaded features:

    0 enumerator.so
    1 rational.so
    2 complex.so

I always thought Enumerable#any? was equivalent to Enumerable#count > 1

But no…

[nil, nil, nil].any?
#=> false

I love PacMan but I am not good at it, not even if my own neighbourhood.

Interesting problem requiring us to remove the where values on an ActiveRecord::Relation. The original heavy handed method seems to play havoc with chained where calls and the id of the original proxy_association.owner would get used in a later where. Here we can see that our for_me method seems to cause the else_id to be the same as our recipient_id

[5] pry(#<RSpec::Core::ExampleGroup::Nested_1::Nested_7::Nested_1>)> user.somethings.where(else_id: something.else_id).to_sql
=> "SELECT `somethings`.* FROM `somethings` WHERE `somethings`.`user_id` = 20323 AND `somethings`.`else_id` = 6465  ORDER BY id DESC"
[6] pry(#<RSpec::Core::ExampleGroup::Nested_1::Nested_7::Nested_1>)> user.somethings.for_me.where(else_id: something.else_id).to_sql
=> "SELECT `somethings`.* FROM `somethings` WHERE `somethings`.`recipient_id` = 20323 AND `somethings`.`else_id` = 20323  ORDER BY id DESC

when in doubt read the Rails source

# remove user_id = proxy_association.owner.id from scope
    # so it can be reapplied by to_me or for_me
    def global_scope
-      s = respond_to?(:scoped) ? scoped : all
-      s.where_values = []
-      s
+      unscope(where: :user_id)
    end

which is the way that rewhere reassigns values in where rather than chaining again

2.2.2 :006 > Something.where(user_id: 1).where(user_id: 2).to_sql
=> "SELECT `somethings`.* FROM `somethings` WHERE `somethings`.`user_id` = 1 AND `somethings`.`user_id` = 2"
2.2.2 :007 > Something.where(user_id: 1).rewhere(user_id: 2).to_sql
=> "SELECT `somethings`.* FROM `somethings` WHERE `somethings`.`user_id` = 2"

class Creature < ActiveRecord::Base
    scope :is_good_pet, -> {
        where(
            arel_table[:is_cat].eq(true)
            .or(arel_table[:is_dog].eq(true))
            .or(arel_table[:eats_children].eq(false))
        )
    }
end

Nice…

class Person < ActiveRecord::Base
  has_many :pets
end

person.pets.count # => 1
person.pets.many? # => false

person.pets << Pet.new(name: 'Snoopy')
person.pets.count # => 2
person.pets.many? # => true