I have an "audit" table that records when changes are made to another table. If a record is destroyed, I don''t want all the change audits for that record destroyed or nullified along with it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Dec 16, 2008 at 10:29 AM, Ed Lebert <edlebert-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I have an "audit" table that records when changes are made to another > table. If a record is destroyed, I don''t want all the change audits > for that record destroyed or nullified along with it. > > How about :dependent => :nullify, or perhaps not attaching :dependent atall to your model which (I am presuming) :has_many of the other model? --wpd --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
@Ed: Just leave the :dependent option off completely and nothing happens to the other records. That''s the default behavior. On Tue, Dec 16, 2008 at 10:37 AM, Patrick Doyle <wpdster-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Tue, Dec 16, 2008 at 10:29 AM, Ed Lebert <edlebert-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> I have an "audit" table that records when changes are made to another >> table. If a record is destroyed, I don''t want all the change audits >> for that record destroyed or nullified along with it. >> > How about :dependent => :nullify, or perhaps not attaching :dependent at all > to your model which (I am presuming) :has_many of the other model? > > --wpd > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I think a better question is, "Why isn''t there a :dependent => :deny option?" It''s very common to have a relational dependency where you want to deny the deletion of an object that has related objects. It would be really nice if this referential integrity rule was part of Rails core rather than having to write it yourself or use a plugin. It doesn''t seem to me that it would be too difficult to add, if the count of the related objects is greater than zero deny the deletion. Example: Employee belongs_to :department Department has_many :employees, :dependent => :deny Deny deletion of a department if the department contains one or more employees. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Robert Walker wrote:> I think a better question is, "Why isn''t there a :dependent => :deny > option?"Because Josh said no. http://dev.rubyonrails.org/ticket/3837 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Department > has_many :employees, :dependent => :denyhas_many :employees, :dependent => ''something'' indicates what non-default behavior to apply to the :employees... not some behavior related to the :department we already have a :before_destroy callback to serve your purpose, which is far more powerful -- not every case is as simple as "Don''t delete if there are any employees" -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
James Byrne wrote:> Robert Walker wrote: >> I think a better question is, "Why isn''t there a :dependent => :deny >> option?" > > Because Josh said no. > > http://dev.rubyonrails.org/ticket/3837That''s a good answer, I''ll accept that. Ar Chron wrote:> we already have a :before_destroy callback to serve your purpose, which > is far more powerful -- not every case is as simple as "Don''t delete if >there are any employees"This also makes sense. Especially in the context of Rails. Having a "deny delete" or "protect from delete" as implemented in other frameworks I''ve used also makes sense in their own right. But, it is true that this is more a validation issue than an association issue, so also makes sense to be implemented in the context of validation. The line can get a bit fuzzy when talking about "relational integrity" since it takes both association manipulation (cascade delete and nullify) and validation (deny delete) in order to fully implement. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---