drizzle-discuss team mailing list archive
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;
That yields false. Yay!
Since PHP 4.0.7 you could use:
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'
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.