php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #39618 Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
Submitted: 2006-11-24 14:56 UTC Modified: 2007-08-25 01:00 UTC
From: randy at rcs-comp dot com Assigned:
Status: No Feedback Package: Documentation problem
PHP Version: 5.2.0 OS: Windows XP
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
1 + 23 = ?
Subscribe to this entry?

 
 [2006-11-24 14:56 UTC] randy at rcs-comp dot com
Description:
------------
After using prepare() & execute() to retrieve a PDO Statement from a PDO Sqlite2 connection, subsequent calls to exec() return a "rows affected" value that appears to sum the previous calls to exec() together.

Reproduce code:
---------------
http://www.rcs-comp.com/phpcode/simple_pdo_test3.php.txt

Expected result:
----------------
>php simple_pdo_test3.php
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 3
statement preped and all records retrieved
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 3
rows updated w/ exec() (some): 2 2
rows updated w/ prep & execute() (all): 3 3


Actual result:
--------------
>php simple_pdo_test3.php
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 3
statement preped and all records retrieved
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 5 <-- notice the addition from the prev. row
rows updated w/ exec() (some): 2 7 <-- notice the addition from the prev. row
rows updated w/ prep & execute() (all): 3 3 <-- problem disappears


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-28 11:07 UTC] tony2001@php.net
See http://www.sqlite.org/cvstrac/tktview?tn=383

"The sqlite_changes API function returns the number of rows that have been inserted, deleted, or modified since the database was last quiescent. A "quiescent" database is one in which there are no outstanding calls to sqlite_exec and no VMs created by sqlite_compile that have not been finalized by sqlite_finalize."

This is how it is supposed to work in Sqlite2, but Sqlite3 seems to work differently.
 [2006-11-28 14:20 UTC] randy at rcs-comp dot com
Tony,

Thank you for your time on this and the explanation.  However, I still think this represents a bug in PHP for three reasons.

1)  The documentation says "PDOStatement::rowCount --  Returns the number of rows affected by the last SQL statement"

Notice that it says "the last" SQL statement.  In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement."  This function does not work the way the documentation says it does, and is therefore buggy.

2)  I understand what you are saying about "this is how it is supposed to work in Sqlite2."  However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly.  PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers.  If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it.

3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2.  This is a huge incompatability for the SQLite 2 driver.

I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug.
 [2006-11-28 14:22 UTC] tony2001@php.net
Reclassified as docu problem.
 [2006-11-28 14:26 UTC] randy at rcs-comp dot com
THIS IS NOT A DOCUMENTATION PROBLEM!!!  The documentation describes the best way for the function to work.

It is a problem with a PDO driver not working like every other PDO driver!  What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers!!!!

If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you.  If so, I will leave the bug report alone.

Thank you.
 [2006-11-28 14:36 UTC] tony2001@php.net
The very same issue in SQLite bug db (http://www.sqlite.org/cvstrac/tktview?tn=383) has beem resolved by adding it to the docs.
If you think it's wrong, then you can report it to SQLite developers and persuade them to fix it in SQLite.

Since this is the way SQLite works, we can't fix it in PHP and this should be documented.

>If you insist that this is a documentation problem
Yes, I do.

>will you please have another PHP developer chime in and agree with you.
No, thank you.
 [2006-11-28 14:39 UTC] randy at rcs-comp dot com
Another reason it is a bug is because the PDO SQLite2 driver is inconsistent itself!

Notice that the bug only appears after a prepared statement is requested.  If this is not a bug, then under "Actual Results" I should have:

>php simple_pdo_test3.php
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5"
statement preped and all records retrieved
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 5 
rows updated w/ exec() (some): 2 7
rows updated w/ prep & execute() (all): 3 3
 [2006-11-28 14:42 UTC] randy at rcs-comp dot com
Tony,

Sorry, I am not going to let this one drop unless someone else chimes in.  I have been around bugs.php.net to know that you are reluctant to fix bugs that are truly bugs.  Case in point:

http://bugs.php.net/bug.php?id=37846

This is a bug and not a documentation problem!
 [2006-11-28 14:44 UTC] randy at rcs-comp dot com
"Since this is the way SQLite works, we can't fix it in PHP and this
should be documented."

It may be true that SQLite works this way, but if that is the case, then PHP should work around this for the SQLite2 driver so that the PDO interface is consistant.  The PHP developer should not have to be concerned with driver specific details like this.
 [2006-11-28 14:52 UTC] tony2001@php.net
>It may be true that SQLite works this way, but if that is 
>the case, then PHP should work around this for the SQLite2 
>driver so that the PDO interface is consistant. 

.. or document it.
Please let developers to decide what to do with such kind of problems.
 [2006-11-28 14:56 UTC] randy at rcs-comp dot com
Then please address the inconstancy in the driver itself.  I will repost for ease of reference:

Notice that the bug only appears after a prepared statement is
requested.  This means the driver itself is inconsistent in what it returns.  If this is not a bug, then under "Actual Results" I should
have:

>php simple_pdo_test3.php
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this
should say "3 5"
statement preped and all records retrieved
rows updated w/ exec() (some): 2 2
rows updated w/ exec() (all): 3 5 
rows updated w/ exec() (some): 2 7
rows updated w/ prep & execute() (all): 3 3
 [2006-11-30 09:35 UTC] tony2001@php.net
The only thing we can do about *SQLite* inconsistencies and problems is DOCUMENT THEM.
Please do not touch the report anymore, if you don't have a patch yourself and not going to do anything about it anyway.
Thank you.

 [2006-11-30 13:07 UTC] randy at rcs-comp dot com
I will not leave this bug report alone until you address the fact that the SQLite 2 driver itself is inconsistent in the way it returns row counts.  Please see my last post.
 [2006-11-30 14:22 UTC] randy at rcs-comp dot com
I have contacted another PHP developer and they agreed with you Tony.  My apologies for stringing this out so long and taking up your time.
 [2006-12-01 10:51 UTC] tony2001@php.net
Oh, I can't believe that.
 [2006-12-01 14:13 UTC] randy at rcs-comp dot com
>Oh, I can't believe that.

1)  For what it is worth, which apparently is nothing since I am only a PHP user and not a PHP developer, this is still a bug in my opinion.  However, if the PHP developers choose to ignore these kind of things in favor of documentation, the only thing I can do is write a sub-class and fix the bugs I come across.  I am sure it will be popular...

2)  Part of the reason this drew on so long is because of your reputation on this site for not addressing problems in a helpful way.  You seem quick to mark something bogus or as some else's problem instead of really looking into the bug yourself.  If you were more helpful, I might have just taken your word on this one.

3)  Your comment above demonstrates your arrogance, which hinders you from coming across as someone who really cares about PHP and wants to make it better.  PHP developers have no purpose without PHP users.  You should think on that one for a while.  And then try to let it affect your attitude when answering bug reports.

4)  This is not the forum for your comment above or my comments in this post, but you started it ...  lets move on
 [2006-12-01 14:28 UTC] tony2001@php.net
Just imagine what would you think if I said "find 2000 and 1 users that think it's a bug and I'll agree with you". Doesn't it sound like a nonsense to you? Of course it does. But you did the very same thing.
And yes, I understand that you'll keep arguing forever and will not admit that you might be wrong.
Yes, I know very well it's not a forum, thank you.
 [2006-12-01 14:46 UTC] randy at rcs-comp dot com
Honestly, I don't think it is nonsense at all.  That kind of principle is inherent in the voting system right?  Obviously, 2000 and 1 would be a little drastic.  However, I only asked for one other opinion.

So, lets say that I found 10 other PHP users who felt this was a bug and would like to see PHP developers address the problem internally.  Would you then be willing to look into fixing it?  I am willing to do that if you are willing to fix it.
 [2007-08-17 11:46 UTC] vrana@php.net
What exactly should be documented?
 [2007-08-25 01:00 UTC] phpdoc at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 06:01:29 2024 UTC