#32724 [NEW]: sqlite_free_result would be useful for some transaction scenarios
From: victor-php at boivie dot com
Operating system: Not important
PHP version: 5.0.4
PHP Bug Type: SQLite related
Bug description: sqlite_free_result would be useful for some transaction
scenarios
Description:
This is a function FEATURE REQUEST and not a real bug. But it's SQLite
related so I put it there instead.
When you start a transaction and want to do a SELECT and then an UPDATE
(for example), the results from the SELECT-query must be finished before
you are allowed to UPDATE (due to the table locking)
This means that you must step through all rows of the resultset (until the
sqlite_fetch_xxx returns false). In some cases, it would be good to
prematurely finish a SELECT-resultset to be able to do an UPDATE without
having to loop through all remaining rows.
Thus, a sqlite_free_result() function would be useful.
Reproduce code:
---
$db = sqlite_open("test.db");
sqlite_exec($db, "BEGIN TRANSACTION");
$res = sqlite_unbuffered_query($db, "SELECT * FROM temp");
$row = sqlite_fetch_array($res);
sqlite_exec($db, "UPDATE temp SET value=10 WHERE id=1");
sqlite_exec($db, "END TRANSACTION");
sqlite_close($db);
Expected result:
Well, I expect it to fail.
With a sqlite_free_result($res) after the sqlite_fetch_array-statement I
would expect it to work.
A workaround is, (after you have retrieved your important results from the
SELECT), to do a
while (sqlite_fetch_array($res));
... to step through the remaining rows.
Actual result:
--
Well, it fails as I expected.
--
Edit bug report at http://bugs.php.net/?id=32724&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32724&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32724&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32724&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32724&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32724&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32724&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32724&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32724&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32724&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32724&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32724&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32724&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32724&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32724&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32724&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32724&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32724&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32724&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32724&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32724&r=mysqlcfg
#32724 [Fbk->Opn]: sqlite_free_result would be useful for some transaction scenarios
ID: 32724
User updated by: victor-php at boivie dot com
Reported By: victor-php at boivie dot com
-Status: Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Not important
PHP Version: 5.0.4
New Comment:
That actually produces correct results. So setting a resource to null
frees the resource?
http://se2.php.net/manual/en/language.types.resource.php mentions that
"Due to the reference-counting system ... it is automatically detected
when a resource is no longer referred to .. all resources that were in
use for this resource are made free by the garbage collector. For this
reason, it is rarely ever necessary to free the memory manually by
using some free_result function."
So it is actually noted in the manual. However, for symmetry in the PHP
language, I still think it's a good idea to have a sqlite_free_result
that does exactly this, as there is for many other databases (every
other?). It would be more intuitive anyway - what do you think?
Thanks for your help!
Previous Comments:
[2005-04-16 00:23:56] [EMAIL PROTECTED]
$res = null;
not good enough?
[2005-04-15 21:11:52] victor-php at boivie dot com
Description:
This is a function FEATURE REQUEST and not a real bug. But it's SQLite
related so I put it there instead.
When you start a transaction and want to do a SELECT and then an UPDATE
(for example), the results from the SELECT-query must be finished before
you are allowed to UPDATE (due to the table locking)
This means that you must step through all rows of the resultset (until
the sqlite_fetch_xxx returns false). In some cases, it would be good to
prematurely finish a SELECT-resultset to be able to do an UPDATE without
having to loop through all remaining rows.
Thus, a sqlite_free_result() function would be useful.
Reproduce code:
---
$db = sqlite_open("test.db");
sqlite_exec($db, "BEGIN TRANSACTION");
$res = sqlite_unbuffered_query($db, "SELECT * FROM temp");
$row = sqlite_fetch_array($res);
sqlite_exec($db, "UPDATE temp SET value=10 WHERE id=1");
sqlite_exec($db, "END TRANSACTION");
sqlite_close($db);
Expected result:
Well, I expect it to fail.
With a sqlite_free_result($res) after the sqlite_fetch_array-statement
I would expect it to work.
A workaround is, (after you have retrieved your important results from
the SELECT), to do a
while (sqlite_fetch_array($res));
... to step through the remaining rows.
Actual result:
--
Well, it fails as I expected.
--
Edit this bug report at http://bugs.php.net/?id=32724&edit=1
#32724 [WFx]: sqlite_free_result would be useful for some transaction scenarios
ID: 32724
User updated by: victor-php at boivie dot com
Reported By: victor-php at boivie dot com
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: Not important
PHP Version: 5.0.4
New Comment:
I respect your opinion, but might I ask you _what_ your pet hate is?
The SQLite extension? The *_free_result-functions?
If it is just personal and not for the good of the PHP language, I
might consider implementing it myself (sending a patch to the php-dev
group)
Previous Comments:
[2005-04-18 01:11:51] [EMAIL PROTECTED]
This is actually one of my pet hates in PHP.
I won't be implementing it.
[2005-04-17 14:54:14] [EMAIL PROTECTED]
moving to the right category..
[2005-04-16 09:10:20] victor-php at boivie dot com
That actually produces correct results. So setting a resource to null
frees the resource?
http://se2.php.net/manual/en/language.types.resource.php mentions that
"Due to the reference-counting system ... it is automatically detected
when a resource is no longer referred to .. all resources that were in
use for this resource are made free by the garbage collector. For this
reason, it is rarely ever necessary to free the memory manually by
using some free_result function."
So it is actually noted in the manual. However, for symmetry in the PHP
language, I still think it's a good idea to have a sqlite_free_result
that does exactly this, as there is for many other databases (every
other?). It would be more intuitive anyway - what do you think?
Thanks for your help!
[2005-04-16 00:23:56] [EMAIL PROTECTED]
$res = null;
not good enough?
[2005-04-15 21:11:52] victor-php at boivie dot com
Description:
This is a function FEATURE REQUEST and not a real bug. But it's SQLite
related so I put it there instead.
When you start a transaction and want to do a SELECT and then an UPDATE
(for example), the results from the SELECT-query must be finished before
you are allowed to UPDATE (due to the table locking)
This means that you must step through all rows of the resultset (until
the sqlite_fetch_xxx returns false). In some cases, it would be good to
prematurely finish a SELECT-resultset to be able to do an UPDATE without
having to loop through all remaining rows.
Thus, a sqlite_free_result() function would be useful.
Reproduce code:
---
$db = sqlite_open("test.db");
sqlite_exec($db, "BEGIN TRANSACTION");
$res = sqlite_unbuffered_query($db, "SELECT * FROM temp");
$row = sqlite_fetch_array($res);
sqlite_exec($db, "UPDATE temp SET value=10 WHERE id=1");
sqlite_exec($db, "END TRANSACTION");
sqlite_close($db);
Expected result:
Well, I expect it to fail.
With a sqlite_free_result($res) after the sqlite_fetch_array-statement
I would expect it to work.
A workaround is, (after you have retrieved your important results from
the SELECT), to do a
while (sqlite_fetch_array($res));
... to step through the remaining rows.
Actual result:
--
Well, it fails as I expected.
--
Edit this bug report at http://bugs.php.net/?id=32724&edit=1
#29159 [NEW]: readfile (or fpassthru or even php_stream_passthru) can not output large++ file
From: victor-php at boivie dot com Operating system: FreeBSD 4.7 PHP version: 5.0.0 PHP Bug Type: Filesystem function related Bug description: readfile (or fpassthru or even php_stream_passthru) can not output large++ file Description: victor:~> php -v PHP 5.0.0RC2 (cgi) (built: Apr 30 2004 08:15:25) (oh well, this issue still exists in 5.0.0) victor:~> grep output /usr/local/lib/php.ini output_buffering = 4096 output_handler = zlib.output_compression = Off victor:~> ls -l test.fil -rw-r--r-- 1 root wheel 734939136 Oct 14 2003 test.fil As the results shows, PHP tries to allocate the whole file in memory which is bad. I thought php_stream_passthru used a small buffer and that it didn't allocate the whole file, but I'm not familiar with the PHP source code. Reproduce code: --- Expected result: A lot of file data in the browser window (the file contents) Actual result: -- PHP Fatal error: Out of memory: cannot allocate 734941208 bytes! in /usr/home/victor/foo.php on line 2 Content-type: text/html X-Powered-By: PHP/5.0.0RC2 Fatal error: Out of memory: cannot allocate 734941208 bytes! in /usr/home/victor/foo.php on line 2 -- Edit bug report at http://bugs.php.net/?id=29159&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29159&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29159&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29159&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29159&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29159&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29159&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29159&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29159&r=support Expected behavior: http://bugs.php.net/fix.php?id=29159&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29159&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29159&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29159&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29159&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29159&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29159&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29159&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29159&r=float
#29339 [NEW]: sqlite_escape_string returns bogus data for empty strings on Windows XP
From: victor-php at boivie dot com
Operating system: Windows XP
PHP version: 5.0.0
PHP Bug Type: SQLite related
Bug description: sqlite_escape_string returns bogus data for empty strings on Windows
XP
Description:
sqlite_escape_string returns bogus data for empty strings on Windows XP.
In FreeBSD with PHP 5.0.0RC2, it works.
Reproduce code:
---
php.exe -r "echo sqlite_escape_string('');"
Expected result:
(nothing)
Actual result:
--
a few letters from the lower part of the ASCII table. And they can not
easily be shown here.
--
Edit bug report at http://bugs.php.net/?id=29339&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29339&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29339&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29339&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29339&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29339&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29339&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29339&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29339&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29339&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29339&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29339&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29339&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29339&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29339&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29339&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29339&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29339&r=float
#29341 [NEW]: $bar = empty(trim($foo)) ? 1 : 0 will generate error
From: victor-php at boivie dot com Operating system: FreeBSD, Windows XP PHP version: 5.0.0 PHP Bug Type: Scripting Engine problem Bug description: $bar = empty(trim($foo)) ? 1 : 0 will generate error Description: Look at the reproducable code below. Reproduce code: --- $foo = ""; // Doesn't matter $bar = empty(trim($foo)) ? 1 : 0; echo $bar; Expected result: 1 Actual result: -- Fatal error: Can't use function return value in write context in bug.php on line 2 -- Edit bug report at http://bugs.php.net/?id=29341&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29341&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29341&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29341&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29341&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29341&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29341&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29341&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29341&r=support Expected behavior: http://bugs.php.net/fix.php?id=29341&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29341&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29341&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29341&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29341&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29341&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29341&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29341&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29341&r=float
