Everything

php

Re: database driver: no more rows

php.internals

Unnamed Person

22 years ago

In a message dated 10/22/2003 6:00:11 PM Eastern Daylight Time, andi@zend.com
writes:
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:

>>Err .. I don't agree.
>>Null means no data
>>False means error.
>
>Maybe historically (PHP-wise) it does.
>But the way I see it, every fetch() can 'fail' for two reasons: an
>expected well-defined reason (eof), and an unexpected undefined reason
>(error). Labelling the well-defined reason as 'false' and the undefined
>reason as 'null' is really quite defendable.

This isn't something I'd like to see changed. I actually think there are
probably lots of people who do !== false and we could screw up a lot of
scripts. I see the advantage of being able to tell the difference but I
think it's not big enough to change it now.

Andi
Well, this would be my first time contributing to any discussion on this list
since I joined, but I have a question.

It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so much
different than PHP 4 that scripts would have to be somewhat rewritten for it
anyway? (I'm not saying that PHP 5 is totally different, just different enough.)

I don't think I've had any experince with those functions returning FALSE for
me, but I think it's more logical that they differentiate between the FALSE
and the NULL for the reasons stated above.

Gordon Hemsley

Andi Gutmans

22 years ago

At 06:04 PM 10/22/2003 -0400, GPHemsley@aol.com wrote:

>Well, this would be my first time contributing to any discussion on this
>list since I joined, but I have a question.
>
>It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so
>much different than PHP 4 that scripts would have to be somewhat rewritten
>for it anyway? (I'm not saying that PHP 5 is totally different, just
>different enough.)
>

For PHP applications which are mostly functional there will be very little
which will need to be fixed (if at all). Many OOP applications will also
work and only some will need fixing. There will hopefully be a relative
small amount of BC problems, and where BC was broken it was usually only
when it was crucial.

>I don't think I've had any experince with those functions returning FALSE
>for me, but I think it's more logical that they differentiate between the
>FALSE and the NULL for the reasons stated above.

How is this dealt with today?

Andi

Lukas Smith

22 years ago

> From: Andi Gutmans [mailto:andi@zend.com]
> Sent: Thursday, October 23, 2003 12:06 AM

> >I don't think I've had any experince with those functions returning FALSE
> >for me, but I think it's more logical that they differentiate between the
> >FALSE and the NULL for the reasons stated above.
>
> How is this dealt with today?

Well when you get a return value of false you check if there is an error.
But in some ext there is no way in easily determining if an error was
created by the fetch call or by some other function call to the ext.

run query that works
run query that doesn't

now when you fetch the rows of the first query you will usually determine if
you hit the end if the result set by checking if you don't get an array
returned

if you don't get an array you check for an error and in several ext you will
get the error created by the second query. This is also caused by the fact
that the error checking simply returns the last error which cant be cleared
appearently.

this effectively means that for example in the mysql, mssql, sybase (maybe
some other drivers) in PEAR DB we had to remove error checking in the fetch
method.

But I guess you are right .. this is just a minor limitation and if you are
reluctant to accept a BC break to clean up minor limitations then its not
something that will ever get fixed (it could of course be fixed in new
extensions).

Regards,
Lukas