Optimistic Locking starts with nil?

Question

Let me preface this by saying that the behavior of rails optimistic locking seems to be working, I'm simply trying to understand why my unit test is returning the value it is. When running my unit test, to check if the lock_version increments, and assert_not_equal I get a passing test. And when I set the test to assert_equal it fails, but the message returns nil instead of 0. Why?

lock_version details Data_type => Number(38,0), Nullable => No, Data_default => 0

Unit Test

  test "optimistic locking increments" do
    invoice = create(:invoice)
    first  = Invoice.find(invoice.invoice_id)
    second = Invoice.find(invoice.invoice_id)
    first.currency  = "GBP"
    second.currency = "EUR"
    first.save
    second.save
    assert_equal first.lock_version, second.lock_version 
  end

Expected: nil Actual: 1

UPDATE

When I change the test to assert_not second.save it fails. My understanding is that the optimistic locking should prevent saving(updating) the second value. Why might it not be?

As per Kristján's suggestion first.lock_version returns "", not 0

Can you print your `lock_version`s right after you find the objects to verify your DB default is 0? Otherwise, optimistic locking will leave it `nil` until it successfully updates. — Kristján, May 02 '16 at 15:12
Printing the first.lock_version after finding the object returns nothing. And even if I specify it as 0 in my factory it still comes out as nothing. Looking at the model in SQL Developer I'm getting the confirmation that the default is 0, but your suggestion to print it makes me question if I'm missing something else. — CheeseFry, May 02 '16 at 15:23

score 0 · Accepted Answer · answered May 03 '16 at 16:55

When I generated my lock_version column I used the following migration.

class AddLockVersionToInvoice < ActiveRecord::Migration
  def change
    add_column :ch_invoice, :lock_version, :integer, default: 0, null: false
  end
end

gems

ruby-oci8 (2.2.1) activerecord-oracle_enhanced-adapter (1.6.7, 1.6.6)

Somehow this combination doesn't work. Removing null:false and recreating objects in the database DID fix it. Not sure if this is a known bug, or not but a colleague of mine will get a chance to talk with someone working on the enhanced-adapter gem and see if we can get any more insights.

With the above changes the optimistic locking behavior is functioning. N.B. The migration I orginally used originated from this railscast.

Optimistic Locking starts with nil?

1 Answers1