After I do x.destroy on AR descendant x, is there any method I can call
on x to determine that it was destroyed.
x.new_record? returns false
x.id returns the previous primary key (now gone since the destroy).
Thanks,
Wes
After I do x.destroy on AR descendant x, is there any method I can call
on x to determine that it was destroyed.
x.new_record? returns false
x.id returns the previous primary key (now gone since the destroy).
Thanks,
Wes
x.frozen? will tell you because these objects are frozen after destroy.
This will work as long as you are not freezing objects for another
reason.
Wes G. wrote:
After I do x.destroy on AR descendant x, is there any method I can call
on x to determine that it was destroyed.x.new_record? returns false
x.id returns the previous primary key (now gone since the destroy).Thanks,
Wes
–
Sincerely,
William P.
After I do x.destroy on AR descendant x, is there any method I can call
on x to determine that it was destroyed.x.new_record? returns false
x.id returns the previous primary key (now gone since the destroy).
x.frozen?
I believe will return true if the object has been destroyed.
Philip H. wrote:
After I do x.destroy on AR descendant x, is there any method I can call
on x to determine that it was destroyed.x.new_record? returns false
x.id returns the previous primary key (now gone since the destroy).x.frozen?
I believe will return true if the object has been destroyed.
My testing shows that frozen? returns false.
I am on Rails 1.1.6 if that matters.
Wes
That’s right.
“Deleting” this object really means moving all of it’s child data to
archive tables and then marking it (the parent) as deleted.
Don’t ask - this is existing functionality from the system I’m
integrating into.
So, in fact, the record is not removed because I overrode “destroy.”
My bad.
Thanks for the help guys.
Wes
Wes G. wrote:
That’s right.
“Deleting” this object really means moving all of it’s child data to
archive tables and then marking it (the parent) as deleted.Don’t ask - this is existing functionality from the system I’m
integrating into.
That’s actually not that unusual. There’s even a Rails plugin
acts_as_paranoid that does a similar thing.
–
Michael W.
I use acts_as_paranoid, and it still freezes the object once you destroy
it even though the row is not removed. You may want to add that to your
overridden destroy to keep you from accidentally modifying your
“deleted” items. It’s simple to do, just call x.freeze and you are all
set.
Wes G. wrote:
My bad.
Thanks for the help guys.
Wes
–
Sincerely,
William P.
My testing shows that frozen? returns false.
I am on Rails 1.1.6 if that matters.
Strange. I am too and my test returned true.
x = MyModel.find(:first)
x.destroy
x.frozen?
yielded true.
This was via console…
I did add this.
As it turns out, I really need to be able to do a standard AR destroy in
certain situations.
So I’ve decided to rename my overridden “destroy” method to “deactivate”
since I need access to destroy anyway, and the “destroy” name implies
destruction, not the archiving of records.
Thanks for all the help,
Wes
aap will do a volatile delete if you use the :destroy! method on the
object.
On Oct 4, 12:11 pm, Wes G. [email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs