@chrisdavenport Do you think this issue with PDO should be addressed?

Until these last couple of days I hadn't even looked at PDO, but having read some of their documentation now I'm wondering why anyone would even consider using it in the first place. It supposedly abstracts away the differences between the different databases, but it is littered with exceptions that require workarounds, often on the most basic of requests.

I think that if we are going to continue to support PDO then we will need to make a list of the underlying databases that we are going to support in combination with it and write the tests that will prove interoperability with them. Otherwise we'd just be raising people's expectations that it will work with any database supported by PDO, when the reality is it won't. And that's not our fault.

I totally agree, PDO is currently bad at best, a disaster at worst.

Note: I don't use PDO, I only came across this PDO quark in answering someone's question on getNumRows() (the documentation didn't properly reflect the function's actual result at that time)
In applying the documentation correction, I checked and found that PDO has a significantly different behavior from MySQL and MySQLi.

Is this still a valid issue in the current staging. There was a change relating to PDO recently

I believe this is still an issue. The only change to pdo was in d4aa0c2 to add exceptions to the driver

Can you check please as there was also a change to force strict mode off
(to match mysql and mysqli drivers).

On 10 May 2016 at 20:20, Walt Sorensen notifications@github.com wrote:

I believe this is still an issue. The only change to pdo was in d4aa0c2
d4aa0c2
to add exceptions to the driver

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8571 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

From a quick look at the code (I'm on my phone and can't test), the issue described is still there.

@brianteeman taking a deeper look, The code is the same as it was was when this issue was opened.

The problem relates to the use of PDOStatement::rowCount() in the function, details in the link

Ping @csthomas @alikon

What are your thoughts on this issue with the use of PDOStatement::rowCount() in the function getNumRows() causing the function to not be vaild for SELECT statement?

/Ping @csthomas @alikon @mbabker @wilsonge

What are your thoughts on this issue with the use of PDOStatement::rowCount() in the function getNumRows() causing the function to not be vaild for SELECT statement?

Is this an issue or shall we close this?

I see only one solution as you mentioned, means SELECT COUNT(*)

I do not sure about this line:
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/database/driver/pdo.php#L618

when I compare it with:
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/database/driver/pdo.php#L638

but I'm not familiar with prepared statement in PDO.

haven't looked at code, but :

A. - PDOStatement::rowCount — Returns the number of rows affected by the last SQL statement

B. - COUNT(*) — Returns one single row with count

therefore the result from A can be different from the result from B
these are different function for different purpose.

see http://us2.php.net/manual/en/pdostatement.rowcount.php

we should use SELECT COUNT(*) if we want one row with count (e.g. SELECT)
we can use PDOStatement::rowCount() if we want the affected rows number (e.g UPDATE,INSERT,DELETE)

@alikon yes,

public function getNumRows($cursor = null) for SELECT query only and we should use SELECT COUNT(*), there may be some exception for certain database in JDatabaseDriverPdo subclasses.

public function getAffectedRows() for UPDATE,INSERT,DELETE and we can use PDOStatement::rowCount()

public function getNumRows($cursor = null) description should be changed.

We should probably create a unit test that shows when this returns the wrong results.

From what I just read it looks like PDOStatement::rowCount() with SELECT might be valid for the PDO_MYSQL driver It's the question of the other databases we support, specifically pgsql

@photodude anything happening here. Its been almost a year since last updated and I dont see the point in having stale issues open forever

@brianteeman I only know about the issue when I discovered it from a method use question came up that resulted in a documentation clarification for the mysqli driver. I don't have the knowledge or skills to address this issue.

Someone with more PDO knowledge and the implications on various supported Databases would have to comment further.

Seems no one is interested in addressing this PDO issue. I don't have the request PDO knowledge about implications on various supported Databases to process further than Identifying this issue.

As there is no movement, I guess this is stale and can be voted to close or keep open pending someone with the necessary PDO skills to address the issue.

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

As this issue doesn't relate to Joomla 4 it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla
cc @zero-24