Yeah, just always use #destroy & .destroy_all, etc., instead of their delete counterparts.
2008/10/9 Francis Fish <[EMAIL PROTECTED]> > On Thu, Oct 9, 2008 at 8:20 AM, Peter Morris <[EMAIL PROTECTED]>wrote: > >> >> On 8 Oct 2008, at 09:22, Francis Fish wrote: >> >> On Wed, Oct 8, 2008 at 6:43 AM, Peter Morris <[EMAIL PROTECTED]>wrote: >> >>> >>> database level constraints are BAD. >>> >>> Don't say something like that when I'm trying to drink my coffee. >> >> I half agree with you, because rspec'ing up things for child entities can >> be a total pain. On the other hand, identifying how you ended up with a load >> of orphaned data without constraints is very difficult. If you had >> constraints turned on then the orphan wouldn't have happened. >> >> >> Ok, but think about how you got those orphans... you deleted parents, >> without cleaning up. ok fine, but the constraint is not FIXING things, it is >> HIDING things. >> >> Those missing orphans where possibly your only clue that something might >> be structurally wrong in your models. but the constraint is hiding that >> information from you. >> >> Don't use constraints to catch sloppy models. >> >> > I'll have to check documentation, but I *think* that using delete_all (by > id and very efficient) may not destroy children even if you've told the > model to. This could lead to a pernicious bug where the tests work but the > running app does not express your intentions correctly. Rpec would check > that delete_all was being called, but not catch that it was the wrong method > to use in these circumstances - an exception from a constraint would show up > straight away. I'm not saying this is good or bad, just that a discussion is > useful. Being able to turn constraints on and off to catch exceptions is a > really useful forensic tool. > > I also agree with your comment in another post about constraints being in > one place - but that could be the database, assuming database exceptions can > be handled gracefully. Then any controller/view combo on top will not > compromise the data. > > I'm ex-Oracle and was trained to think data model integrity first. In fact > we would spend more time on it than anything else. This still feels valid > even now, but you do end up with systems that are technically correct (as in > modelled properly) but unusable (as in you have to jump through 15 screens > creating metadata when you just want to create a quick order line) if you > don't put a user-centric hat on. That's a different discussion though. > > -- > Thanks and regards, > > Francis Fish > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en -~----------~----~----~----~------~----~------~--~---
