On Tue, Aug 19, 2008 at 11:19 AM, csnyder <[EMAIL PROTECTED]> wrote: > On Thu, Aug 14, 2008 at 12:00 PM, Mark Armendariz <[EMAIL PROTECTED]> wrote: > >> I've another project that came in disallowing me to take this project, >> so I'll likely be moving on - but I'm still largely surprised by the >> results. If I had the time to keep a blog, this would likely be a >> very long demonstrative post about the issue, including some eventual >> patches. Hopefully maybe I still can do that some time soon. > > Mark, did they rationalize the MYSQL_STRICT requirement?
It was my own requirement. I've since panned the project, and moved on to a couple far more interesting ones so I haven't really taken this issue much further yet - though I do hope to summarize the whole issue at some point and publish it somewhere on the internets. > I did a > little reading up on that (as I'd never heard of it before this > thread) and it seems like an interesting decision to make, as it will > break most INSERT statements where an auto-incrementing field is in > play. > > By most, I mean any that uses the old standard INSERT INTO table > VALUES ( value1, valuen ); syntax is used. I haven't had much issue with it, personally. I've been using MYSQL_STRICT since late last year. It took me a couple weeks to get used to a few constraints. The most annoying is trying to skip over setting non-null fields on inserts and updates. Also, I prefer to name my columns on inserts. It makes the sql far more legible and easier to debug. > > You get protection from zero-dates (no more 0000-00-00 00:00:00 > values), but is there any other real practical value to running MySQL > in this mode? Overall, the requirement is strictly for development. "Protection", as you mentioned, is key. I find developing in strict mode (p5 and mysql) keeps me from making silly mistakes and hence saves time. Typos are caught (uninitialized vars), I know that my object properties are handled correctly - or even type checked when necessary, my method signatures are lined up, and my queries are tight. It's a red squiggly-lined spell-check for code that helps me make sure I don't make any stupid mistakes leaving me time to deal with my big and ugly ones. For a small project, strict mode generally isn't too big a deal - especially for a one-off script and I'm glad PHP allows strict mode to be shut off, but when a project grows and you find yourself calling methods and objects from hundreds of places throughout a system, it's nice to know these things are in place. An automated test suite might raise the bar for code a few feet. And a decent QA team / plan a few feet more. Strict mode doesn't necessarily make code any better, but it can raise the bar a half an inch or so. The thing that bothers me most here is writing towards strict-mode is pretty easy. Quality assurance can be pretty difficult. Testing correctly, managing bugs, features and project scope, writing decent specifications, more testing correctly, release schedules, database optimization, proper security, team and project management, source control, working with designers all to meet a short deadline and a budget... All these things take a lot of process and practice to get them to run smoothly, and they still won't. Relative to that, writing code to pass the "strict" test is a walk in the park. Forget the walk. It's a swig of good cold beer at a barbecue on a hot-but-not-humid summer day. Simple. Any time I get a code base that doesn't pass strict, it usually just takes me an hour or two to get 80% of the code to stop shouting warnings and notices. And once these habits are set, coding for strict mode is just easy - and the habits are, in my mind, worth the benefit. Of course, when in production, errors are off. Strict mode is off. The essentials are logged. But I know that once it's there, I don't have to worry about warnings and notices. I caught all of them early in the development phase, and likely with the help of my "compiler." That's what strict mode is there for. Sorry, I kinda dragged that rant out, didn't I. Mark _______________________________________________ New York PHP Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
