php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #81376 fetchArray refuses to work with UPDATE ... RETURNING
Submitted: 2021-08-21 19:39 UTC Modified: 2021-08-25 14:18 UTC
From: abrahin dot andrei at yandex dot ru Assigned:
Status: Verified Package: SQLite related
PHP Version: 8.0.9 OS: Arch Linux
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: abrahin dot andrei at yandex dot ru
New email:
PHP Version: OS:

 

 [2021-08-21 19:39 UTC] abrahin dot andrei at yandex dot ru
Description:
------------
---
From manual page: https://php.net/sqlite3result.fetcharray
---


SQLite3Result::fetchArray() returns FALSE on 'UPDATE ... RETURNING ...' even if some rows were affected.

Please note that this interface is fully supported since v3.35, and i have v3.36 installed (as evidenced by output of `SQLite3::version()`).

https://www.sqlite.org/lang_returning.html
https://www.sqlite.org/lang_update.html

Test script:
---------------
$GLOBALS['db'] = new SQLite3('testdb.sqlite');

$db->exec('CREATE TABLE IF NOT EXISTS cron (time INTEGER, type INTEGER, private TEXT');
$db->exec('INSERT INTO cron (time, type, private) VALUES (3, 1, 0)');

$stmt = $db->prepare('UPDATE cron SET time = 10 WHERE time < 10 RETURNING *;');
$res = $stmt->execute();

var_dump($res->fetchArray()); # <-- returns false, should instead return a row




Expected result:
----------------
I expected to see a row full of data and enjoy the possibilities provided by the SQLite v3.36.0

Actual result:
--------------
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-08-23 12:23 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Documentation Problem +Type: Bug
 [2021-08-23 12:23 UTC] cmb@php.net
I can confirm the issue.  It has the same root cause as bug
#64531, namely that SQLite3::execute() already calls
sqlite3_step() to learn if there is a result set or not, and then
resets the statement to be able to start from the beginning.  This
doesn't work for DML statements, though.

I think the only way forward to fix this issue and some others,
would be to drop SQLite3Result altogether, and to move its methods
to SQLite3Statement.  Serious BC break, though.
 [2021-08-23 12:25 UTC] cmb@php.net
> I expected to see a row full of data and enjoy the possibilities
> provided by the SQLite v3.36.0

Use PDO_SQLite instead. :)
 [2021-08-25 09:05 UTC] nikic@php.net
@cmb PDO uses a flag to skip the next step without resetting, maybe we should do that in sqlite3 as well?
 [2021-08-25 14:18 UTC] cmb@php.net
@nikic, see <https://github.com/php/php-src/pull/5204>.
TL;DR: we *need* to drop SQLite3Result altogether.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Oct 28 22:03:34 2021 UTC