# Optimistic locking on #destroy

**URL:** <https://discuss.rubyonrails.org/t/optimistic-locking-on-destroy/37740>\
**Category:** rubyonrails-core\
**Created:** [December 27, 2008, 7:52pm UTC](https://discuss.rubyonrails.org/t/optimistic-locking-on-destroy/37740 "2008-12-27T19:52:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Curtis\_Hawthorne](https://avatars.discourse-cdn.com/v4/letter/c/ecae2f/32.png) [@Curtis\_Hawthorne](https://discuss.rubyonrails.org/u/Curtis_Hawthorne)\
**Post date:** [December 27, 2008, 7:52pm UTC](https://discuss.rubyonrails.org/t/optimistic-locking-on-destroy/37740/1 "2008-12-27T19:52:51Z")

</div>

Hi all,

I just noticed that optimistic locking doesn't seem to affect #destroy calls. This is currently causing me problems because my #after\_destroy handlers can end up using stale data. I could also see it causing trouble if a model had some sort of 'do\_not\_delete' flag that was changed right after AR loaded the record.

So, it seems to me like #destroy should follow the same optimistic locking logic as updates do. That is, add the current lock version to the WHERE clause and raise a StaleObjectError if the delete fails.

I'd be happy to write a patch to fix it, but I wanted to make sure that I understood the issue correctly and that adding this behavior is the correct approach.

Thanks!

Curtis H.