# Optimistic locking problem \[still\] **URL:** \ **Category:** Radiant CMS\ **Created:** [July 4, 2007, 11:37pm UTC](https://www.ruby-forum.com/t/optimistic-locking-problem-still/108577 "2007-07-04T23:37:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![keltia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/da6949/32.png) [@keltia](https://www.ruby-forum.com/u/keltia)\ **Post date:** [July 4, 2007, 11:37pm UTC](https://www.ruby-forum.com/t/optimistic-locking-problem-still/108577/1 "2007-07-04T23:37:07Z")
I did not get any answer last time so I’m posting again: has anyone an idea why when I try to modify and save a given page, I always get this traceback? I can not modify any of my site’s pages so it is a blocking problem ☹ I was using svn for 0.5, went to gems for 0.6.{1,2} and it has not worked since. Using “rake rails:freeze:edge” does not solve the problem. Please help NoMethodError (undefined method `+' for nil:NilClass): /vendor/radiant/vendor/rails/activerecord/lib/active_record/locking/optimist ic.rb:64:in`update\_without\_callbacks’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/callbacks.rb:267 :in `update_without_timestamps' /vendor/radiant/vendor/rails/activerecord/lib/active_record/timestamp.rb:48: in`update’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/base.rb:1789:in `create_or_update_without_callbacks' /vendor/radiant/vendor/rails/activerecord/lib/active_record/callbacks.rb:242 :in`create\_or\_update’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/base.rb:1545:in `save_without_validation' /vendor/radiant/vendor/rails/activerecord/lib/active_record/validations.rb:7 52:in`save\_without\_transactions’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/transactions.rb: 129:in `save' /vendor/radiant/vendor/rails/activerecord/lib/active_record/connection_adapt ers/abstract/database_statements.rb:59:in`transaction’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/transactions.rb: 95:in `transaction' /vendor/radiant/vendor/rails/activerecord/lib/active_record/transactions.rb: 121:in`transaction’ /vendor/radiant/vendor/rails/activerecord/lib/active\_record/transactions.rb: 129:in `save' /vendor/radiant/app/controllers/admin/page_controller.rb:110:in`save’ /vendor/radiant/app/controllers/admin/abstract\_model\_controller.rb:116:in `h andle_new_or_edit_post' /vendor/radiant/app/controllers/admin/page_controller.rb:25:in`edit’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/base.rb:1095:i n `send' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:1095:i n`perform\_action\_without\_filters’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/filters.rb:632 :in `call_filter' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:638 :in`call\_filter’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/filters.rb:438 :in `call' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:637 :in`call\_filter’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/filters.rb:619 :in `perform_action_without_benchmark' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.r b:66:in`perform\_action\_without\_rescue’ /usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/benchmarking.r b:66:in`perform\_action\_without\_rescue’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/rescue.rb:83:i n `perform_action' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/base.rb:430:in`send’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/base.rb:430:in `process_without_filters' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/filters.rb:624 :in`process\_without\_session\_management\_support’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/session\_manage ment.rb:114:in `process_without_test' /vendor/radiant/vendor/rails/actionpack/lib/action_controller/test_process.r b:15:in`process’ /vendor/radiant/vendor/rails/actionpack/lib/action\_controller/base.rb:330:in `process' /vendor/radiant/vendor/rails/railties/lib/dispatcher.rb:41:in`dispatch’ /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.0.1/lib/mongrel/rails.rb:78:in ` process’ ---
**Author:** ![keltia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/da6949/32.png) [@keltia](https://www.ruby-forum.com/u/keltia)\ **Post date:** [July 5, 2007, 12:43am UTC](https://www.ruby-forum.com/t/optimistic-locking-problem-still/108577/2 "2007-07-05T00:43:10Z")
I had the same problem. I think there might be something wrong with the migrations. If you manually set the lock\_version on your database tables to 0 (zero) instead of NULL (which I assume is the problem) you should be ok. I didn’t see you’re earlier email, otherwise I would have responded. Does this work for you? I’ve been meaning to look at the code and submit a patch if necessary but haven’t had time. -Jim ---
**Author:** ![keltia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/da6949/32.png) [@keltia](https://www.ruby-forum.com/u/keltia)\ **Post date:** [July 5, 2007, 12:45am UTC](https://www.ruby-forum.com/t/optimistic-locking-problem-still/108577/3 "2007-07-05T00:45:10Z")
Ollivier, I helped Andrew Vonderluft with this same problem recently. First, make sure you have migrated to the latest version: rake production db:migrate Once you have done that, if it still doesn’t work, use script/console to execute this statement: [:pages, :snippets, :layouts, :users].each do |table| ActiveRecord::Base.connection.execute “UPDATE #{table.to\_s} SET lock\_version = 0 WHERE lock\_version IS NULL” end The issue is that some database adapters don’t respond well to the increment operation when the original value is nil/NULL. When I get to working on some patches, hopefully later this week, I will be updating the migration to do this. I’m sorry for your continued difficulty. Sean ---
**Author:** ![keltia](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/da6949/32.png) [@keltia](https://www.ruby-forum.com/u/keltia)\ **Post date:** [July 5, 2007, 11:24am UTC](https://www.ruby-forum.com/t/optimistic-locking-problem-still/108577/4 "2007-07-05T11:24:53Z")
On 7/5/07, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Once you have done that, if it still doesn’t work, use script/console > to execute this statement: This worked, thanks to Jim and you! > The issue is that some database adapters don’t respond well to the > increment operation when the original value is nil/NULL. I mentionned a while ago thatI’m using postgresql but didn’t in my last mail, sorry. > When I get to working on some patches, hopefully later this week, I > will be updating the migration to do this. I’m sorry for your > continued difficulty. Thanks, I’m back in business 🙂