# Database changes aren't happening in callback before\_destroy()

**URL:** <https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921>\
**Category:** Rails\
**Created:** [January 16, 2009, 4:03pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921 "2009-01-16T16:03:14Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![vikrant](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@vikrant](https://www.ruby-forum.com/u/vikrant)\
**Post date:** [January 16, 2009, 4:03pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921/1 "2009-01-16T16:03:14Z")

</div>

I have a model Model1 with the before\_destory() method defined as  
below.

def before\_destroy  
self.status = ‘deleted’  
self.save!  
return false #don’t want to delete the row.  
end

But in the database the change in the status column doesn’t get  
changed to ‘deleted’

I then tried this

def before\_destory  
self.status = ‘deleted’  
self.save!  
n = Model1.find self.id #Set the breakpoint here in NetBeans IDE.  
return false  
end

I then checked the value of n.status and it was ‘deleted’, but in the  
database it was still ‘active’ (the other value).

I also tried this

Controller1 \< ApplicationController  
def action1  
m = Model1.find params[:id]  
m.destroy  
n = Model1.find m.id #Set the breakpoint here  
end  
end

Even here the value of n.status was ‘deleted’, but in the database it  
was the previous value. (Showed this example just to show that even in  
controller I’m getting the same).

After a bit of of looking through Rails API, I found out that model  
callbacks like before\_destroy are transactional. so they get rolled  
back if any error raised. So I tried this.

def before\_destroy  
self.status = ‘deleted’  
self.save!  
raise self.errors.inspect  
return false  
end

The above code made sure that there are no errors attached, so  
self.save! should run fine (or at least it should raise error!).  
So I don’t know now, why my changes are not being written to the  
database. Is it because I’m returning false from the before\_destroy()  
method? If yes, then how can I save the changes made in before\_destroy  
() callback and also the row doesn’t get deleted?

I’m using SQLite and I’ve also noticed that a ‘development-journal’  
file get created, while I’ve paused the code somewhere in between the  
before\_destroy() method. (That may be the transaction thing, I guess.)

I’m using -  
Rails 2.2.2  
SQLite 3.5.9  
Ubuntu 8.10 (Intrepid) x64

---

<div class="post-metadata">

**Author:** ![vikrant](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@vikrant](https://www.ruby-forum.com/u/vikrant)\
**Post date:** [January 16, 2009, 4:33pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921/2 "2009-01-16T16:33:30Z")

</div>

On 16 Jan 2009, at 15:02, Vikrant wrote:

> But in the database the change in the status column doesn’t get  
> changed to ‘deleted’
> 
> I then tried this
> 
> def before\_destory  
> self.status = ‘deleted’  
> self.save!  
> n = Model1.find self.id #Set the breakpoint here in NetBeans IDE.  
> return false  
> end

Have you tried looking at development log to see exactly what queries  
run ?

Fred

---

<div class="post-metadata">

**Author:** ![vikrant](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@vikrant](https://www.ruby-forum.com/u/vikrant)\
**Post date:** [January 16, 2009, 4:43pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921/3 "2009-01-16T16:43:12Z")

</div>

Yes, just what it should be - UPDATE “model1” SET “updated\_at”  
= …, “status” = “deleted” WHERE id = 40  
but still the database isn’t reflecting that. Also I can not find any  
transaction rollback specific information in the log, as this is the  
last query to the database for that HTTP request.

On Jan 16, 8:32 pm, Frederick C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![vikrant](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@vikrant](https://www.ruby-forum.com/u/vikrant)\
**Post date:** [January 16, 2009, 5:13pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921/4 "2009-01-16T17:13:23Z")

</div>

Well, I can’t find the problem, but I guess I have an alternative  
solution, and that is to use a new method named Model1.make\_deleted()  
which does the deletion work. Also, then I should stop destory() from  
being executed (by raising some kind of exception in before\_destroy()  
method).  
I guess that shall do the work, but I’m still thinking if there is a  
standard way of marking a row as deleted, while not actually deleting  
the row, since the above solution doesn’t seem to be in compliance  
with Rails-way. (Callbacks are made for some purpose after all).

On Jan 16, 8:53 pm, Ilan B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![vikrant](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/cc9497/32.png) [@vikrant](https://www.ruby-forum.com/u/vikrant)\
**Post date:** [January 16, 2009, 4:53pm UTC](https://www.ruby-forum.com/t/database-changes-arent-happening-in-callback-before-destroy/157921/5 "2009-01-16T16:53:39Z")

</div>

Vikrant wrote:

> I have a model Model1 with the before\_destory() method defined as  
> below.
> 
> def before\_destroy  
> self.status = ‘deleted’  
> self.save!  
> return false #don’t want to delete the row.  
> end

Your transaction isn’t completed until the request is completed. If you  
check your DB, you will not see any changes until the request has been  
completed (assuming that your transaction level is beyond dirty reads)

Secondly, you shouldn’t save in a before\_destroy filter

I also believe that returning false will abort the transaction and you  
will be left with an unmodified data source.

ilan