← Back to team overview

drizzle-discuss team mailing list archive

PHP's gaping holes with NULL and why should Drizzle care?

 

Seems like having the php driver perhaps have a behavior more like what
you want it to have would be better? As-in- perhaps we can get the
php-drizzle driver to not set the variable to null when it gets a null
on a datetime column?

Perhaps, but, what should it be? I mean, the field is NULL. The only logical thing for the variable to be in PHP is NULL. Can't be empty string. Not the same. It is complicated by PHP's loose typing of course. It can all be worked around with enough verbosity. You can't simply say:

if($var === null) or if(is_null($var))

Both of those will throw a NOTICE error if $var has not be assigned anything. And to make it worse, you can't check isset().

$var = null;
if(isset($var))

That yields false. Yay!

Since PHP 4.0.7 you could use:

array_key_exists("var", $GLOBALS);

And I guess enough time has passed that we can stop worrying about code older than that. But, a lot of people are set in their ways that PHP and NULL is bad.

Now, should Drizzle worry about the PHP language's inability to deal with NULL. Probably not. I have never liked 0000-00-00 to be honest. Although for different reasons. I will be changing things from:

where expire_date > now() or expire_date='0000-00-00'

to

where expire_date > now() or expire_date is null

Of course, we have adopted different meanings internally for the two now. if an expiration date field is 0000-00-00 it means unknown. If it is NULL it means the item does not expire. Yay! We will have to work around that when (not if dammit) we adopt Drizzle. Again, I don't expect the Drizzle team to worry about that. =)

I have started storing unix timestamps for all dates in new tables. I don't have to worry with 0000-00-00 now in those tables. Of course 0 means something completely different in those cases.

Just expect this to be a hurdle people hit when adopting drizzle.

Brian.



Follow ups

References