php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #32724 sqlite_free_result would be useful for some transaction scenarios
Submitted: 2005-04-15 21:11 UTC Modified: 2005-04-19 05:23 UTC
From: victor-php at boivie dot com Assigned:
Status: Wont fix Package: Feature/Change Request
PHP Version: 5.0.4 OS: Not important
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: victor-php at boivie dot com
New email:
PHP Version: OS:

 

 [2005-04-15 21:11 UTC] 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-04-16 00:23 UTC] wez@php.net 
$res = null;

not good enough?
 [2005-04-16 09:10 UTC] 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-17 14:54 UTC] sniper@php.net 
moving to the right category..
 [2005-04-18 01:11 UTC] wez@php.net 
This is actually one of my pet hates in PHP.
I won't be implementing it.
 [2005-04-18 07:19 UTC] victor-php at boivie dot com 
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)
 [2005-04-19 05:23 UTC] wez@php.net 
The XXX_free and XXX_close functions are redundant and, IMO, potentially confusing.

Resource types in PHP are reference counted and so are automatically freed when the refcount falls to zero.  Resources are typically contained within a zval that has its own refcount.  Variable assignments bump the zval refcount and not the resource refcount.  This is ok for most resources; when the zval refcount falls to zero, it releases the single ref it held on the resource and cleans it up.  Similarly, the XXX_free functions perform the same action.

When you have a more complicated scenario, with the resource having more than one reference on it, calling XXX_free will delete only one reference and not really really free the resource.  This is counter-intuitive; you would expect that call to free it.  So, it is better to not have functions that imply such a final act.

Another argument is that $foo = null; is faster to compile and run than making a function call to foo_free($foo);

In the specific case of sqlite, there should be no problem with a higher than 1 refcount on a resource, so in theory the function could be added.  If you add it, people will start using it, and that will then prompt some backwards compatibility problems in the code that they are writing.
Since we're focusing on PDO for the future, I'd very much prefer it if we didn't add this function to the sqlite extension.

--Wez
(the primary author of the sqlite extension)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Jul 01 10:01:29 2024 UTC