On Oct 10, 2008, at 8:27 am, Peter Morris wrote:
> Ashley, thanks for taking the time to answer so comprehensively. :-) > > Yes, and I acknowledge that I do tend to get a bit dogmatic about DRY. > Fair point. Well, perhaps there's an irony about being critical about DRY given the millions of lines of copy-and-paste garbage out there. But there's such a thing as too much of a good thing. You have to ask, what was DRY supposed to achieve? (The same applies to convention over configuration and all the other mantras.) > Your point regarding the ORM being at fault is a very good one, if you > feel that constraints should > be placed in the DB layer. Well regardless of what caused the save failure, it was naive of the ORM to *assume* it was successful. That was more what I was getting at. > Regarding when you came a cropper, isn't that what testing is for? HAHAHAHAHAHA Sorry I wasn't involved on the code in this app; I just did some DBA work around it. It was legacy in the worst sense of the word (ASP.net 1.1, ugh), and had no tests whatsoever, although some were written later on. > Or > did you have constraints on > the testing database and not the live? I saw a migration fail once because the live DB had a table that was not on the CI server. Someone added it live. Get the picture? :) > Which brings up a valuable point, constraints in the DB can mask > problems at the orm/model layer > and this breaks the principle of 'fail early'. Yes, another > principle. :-( I think DB constraints fit the definition of "fail early", and an ORM reporting a false positive save is demonstrating "be defective early"... > So, there could be a case for having NO constraints on the test > environment, and having constraints > on the live. But this idea is almost certain to have every developer > reading this shouting at the screen. > And rightly. Purposefully making the test and live environments > different is a deep and dark sin, and correctly so. Ohhhh yes. It's like having caching live but not in development. Pretty much guarantees all your bugs will be caching-related... > So, we are back to a conclusion (on my part) that overall, constraints > in the DB makes more harm than > it makes good. Funny, I came to the opposite conclusion ;o) > I love your point about the data being more valuable, yes, that is > very true. But no excuse for having > shoddy AR:B because you can firewall the data away from damage with > constraints. Can you guess which bit of this system I think needs replacing? :) > Disagree with DHH, sure! The minute we stop disagreeing about things, > is the minute we stop advancing. Very, very true. I take a Darwinian approach to things - if someone can build a robust app without DB constraints, fair enough, all the end users care about is that it behaves consistently. But I'm still of the opinion that DB-level integrity is the source of more value than waste, taken over time and projects. Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
