Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #3 (closed task: wontfix)

Opened 4 years ago

Last modified 2 years ago

record.destroy shouldn’t call freeze

Reported by: ror@andreas-s.net Assigned to: David
Priority: 1 Milestone: 1
Component: 1 Version: 1
Severity: 1 Keywords:
Cc:

Description

The following code fails because "record" is frozen after destroy: 

record.destroy
record.parent.destroy # fails

(When foreign key constrains are used it isn’t possible to destroy the parent object first.)

IMO the freezing is unnecessary. If someone wants to change an AR object after deleting it from the DB, why shouldn’t he be allowed to do it?

Change History

10/12/04 00:27:00 changed by anonymous

If you are using foreign keys, couldn't you use a cascading delete to automatically remove the child object at the SQL level?

10/17/04 22:28:21 changed by anonymous

You could, but that is quite beside the point. It fails due to freezing even simply on

self.parent

if/when this causes the parent method to be defined (it is, apparently, defined on the first use)

10/18/04 01:38:24 changed by david

  • status changed from new to closed.
  • resolution set to wontfix.

The use case you presented should be implemented as a before_destroy callback. I like the fact that destroy is a final action. If I could, I'd turn the object reference into nil. You should unravel the dependencies backwards.