3.2.0: Regression in `.where`?

[nialbima]

3.2.0: Regression in `.where`?

[kbrock]

The way relations are created changed quite a bit to follow rails 7.1 trends.
So a bug like there (where it is probably not delegating correctly) makes sense.

Using an active record 6.1 model, this is the functionality I get:

irb(main):001:0> VmOrTemplate.all.spawn.class
=> VmOrTemplate::ActiveRecord_Relation
irb(main):002:0> VmOrTemplate.all.class
=> VmOrTemplate::ActiveRecord_Relation
irb(main):003:0> VmOrTemplate.where(:id => 1).class
=> VmOrTemplate::ActiveRecord_Relation

Are you seeing similar behavior for your active hash model?
If you throw map onto all 3 of the above, do they work for you?

I'm swamped on work right now. Anyone else able to take a peek at this?

[nialbima]

@kbrock if somebody can point me in the right direction, I can take a stab at figuring it out.

[flavorjones]

I'm investigating now!

[flavorjones]

Ok, the problem here is that the attribute :display collides with Object#display.

Specifically, ActiveHash::Relation::Condition uses public_send to send a message by the name of the constraint key, and checks the result against the constraint value:

      constraints.send(expectation_method) do |attribute, expected|
        value = record.public_send(attribute)

        matches_value?(value, expected)
      end

For both objects, the value is nil (so neither matches the display: true constraint) and the response is an empty array, [].

Unfortunately, Object#display has a side effect of emitting information to STDOUT which makes the display garbled. If the output is this:

#<Disposition:0x00000001418dd4b0>#<Disposition:0x00000001418dcab0>#<Disposition:0x00000001418dc5b0>#<Disposition:0x00000001418d7ec0>#<Disposition:0x00000001418d7858>#<Disposition:0x00000001418d71c8>#<Disposition:0x00000001418d6c50>=> []

that's actually seven Disposition objects having #display called on them, followed by the irb prompt => followed by the actual result, [].

So that's the diagnosis, anyway. Not sure about solutions right now.

[flavorjones]

Here's a failing test that I'm working off of:

  describe "colliding methods" do
    it "should handle attributes named after existing methods" do
      klass = Class.new(ActiveHash::Base) do
        self.data = [
          {
            id: 1,
            name: "Aaa",
            display: true,
          },
          {
            id: 2,
            name: "Bbb",
            display: false,
          },
        ]
      end
      expect(klass.where(display: true).length).to eq(1)
    end
  end

[flavorjones]

I started to try to make ActiveHash::Base subclass BasicObject but it's turning into quite an invasive change. Other creative ideas would be welcome, I think.

[flavorjones]

I've submitted a PR at #281, which is a simple fix -- I'd love feedback on whether that's sufficient (or whether it will break untested use cases).