Fixes for using dblib PDO driver. #6612

ajoneil · 2017-02-09T23:26:28Z

These fixes allow *nix environments to connect to SQL Server using
the dblib PDO driver and the silverstripe mssql module.

Only set MYSQL_ATTR_INIT_COMMAND when using the mysql driver, this
constant isn't defined if the mysql pdo driver isn't installed
Supress warnings on getting the server version, attributes aren't
supported by the dblib driver
Explicitly check for errors on sql exec, checking the return
value isn't reliable for statements with no return value (e.g.
USE database)

These fixes allow *nix environments to connect to SQL Server using the dblib PDO driver and the silverstripe mssql module. - Only set MYSQL_ATTR_INIT_COMMAND when using the mysql driver, this constant isn't defined if the mysql pdo driver isn't installed - Supress warnings on getting the server version, attributes aren't supported by the dblib driver - Explicitly check for errors on sql exec, checking the return value isn't reliable for statements with no return value (e.g. USE database)

tractorcow · 2017-02-09T23:42:15Z

model/connect/PDOConnector.php

@@ -227,7 +228,7 @@ public function exec($sql, $errorLevel = E_USER_ERROR) {
 		$result = $this->pdoConnection->exec($sql);

 		// Check for errors
-		if ($result !== false) {
+		if (!$this->hasError($result)) {


The problem is that false as a return value now reports hasError() = false, when before it was hasErrors() = true. Docs on this method:

PDO::exec() returns the number of rows that were modified or deleted by the SQL statement you issued. If no rows were affected, PDO::exec() returns 0.

I think the !== false check was correct.

You could also fix it by making hasError() return true for === false

I'm not sure what you mean by the false return value here - this still returns the result set if the query was successful, or null if there was an error.

The PDO::exec() docs don't match with what I'm seeing - this is returning false with a USE database statement with the dblib driver, but the database select is successful.

I reorganised the code a little here, so it's easier to read.

Er, I mean, false is an error condition. the problem is that the existing hasError() does NOT treat false as an error condition, but rather an empty set.

Before

$result = false; if ($result !== false) { // will not be called }

after

$result = false; if (!$this->hasError($result)) { // WILL be called, oops }

Doh, I pasted the wrong docs snippet.

Warning This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE. Please read the section on Booleans for more information. Use the === operator for testing the return value of this function.

Shouldn't we expect '0' to be non-error, and 'false' to be error?

Hm, more digging confirms what you said. false isn't always an error... I guess I got that understanding wrong I'm sorry!

However, could there yet be cases where false is returned AND there is an error? Perhaps instead of assuming false is automatically true or false, hasError should call errorCode on the connection object? That should meet both of our concerns shouldn't it? :D

since exec() is designed for methods that don't return a result set, I suggest changing the hasError($result) to hasError($this->pdoConnection). Do you think that would work?

dhensby · 2017-02-15T12:56:49Z

Although this is something we can only do in 4, really anything we are finding we have to wrap in "is this a xxx kind of driver" should be logic that each connector provides.

Each connector should provide the connection options, the DSN, and so on.

dhensby · 2017-02-15T12:57:11Z

model/connect/PDOConnector.php

@@ -178,7 +179,7 @@ public function connect($parameters, $selectDB = false) {
 	}

 	public function getVersion() {
-		return $this->pdoConnection->getAttribute(PDO::ATTR_SERVER_VERSION);
+		return @$this->pdoConnection->getAttribute(PDO::ATTR_SERVER_VERSION);


Why do we need to suppress errors here?

"Supress warnings on getting the server version, attributes aren't supported by the dblib driver"

tractorcow · 2017-02-10T04:02:52Z

model/connect/PDOConnector.php

@@ -227,7 +228,7 @@ public function exec($sql, $errorLevel = E_USER_ERROR) {
 		$result = $this->pdoConnection->exec($sql);

 		// Check for errors
-		if ($result !== false) {
+		if (!$this->hasError($result)) {


Er, I mean, false is an error condition. the problem is that the existing hasError() does NOT treat false as an error condition, but rather an empty set.

Before

$result = false; if ($result !== false) { // will not be called }

after

$result = false; if (!$this->hasError($result)) { // WILL be called, oops }

tractorcow · 2017-02-10T04:05:08Z

model/connect/PDOConnector.php

@@ -227,7 +228,7 @@ public function exec($sql, $errorLevel = E_USER_ERROR) {
 		$result = $this->pdoConnection->exec($sql);

 		// Check for errors
-		if ($result !== false) {
+		if (!$this->hasError($result)) {


Doh, I pasted the wrong docs snippet.

Warning This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE. Please read the section on Booleans for more information. Use the === operator for testing the return value of this function.

Shouldn't we expect '0' to be non-error, and 'false' to be error?

tractorcow · 2017-02-10T04:10:17Z

model/connect/PDOConnector.php

@@ -227,7 +228,7 @@ public function exec($sql, $errorLevel = E_USER_ERROR) {
 		$result = $this->pdoConnection->exec($sql);

 		// Check for errors
-		if ($result !== false) {
+		if (!$this->hasError($result)) {


Hm, more digging confirms what you said. false isn't always an error... I guess I got that understanding wrong I'm sorry!

However, could there yet be cases where false is returned AND there is an error? Perhaps instead of assuming false is automatically true or false, hasError should call errorCode on the connection object? That should meet both of our concerns shouldn't it? :D

tractorcow · 2017-02-10T04:12:34Z

model/connect/PDOConnector.php

@@ -227,7 +228,7 @@ public function exec($sql, $errorLevel = E_USER_ERROR) {
 		$result = $this->pdoConnection->exec($sql);

 		// Check for errors
-		if ($result !== false) {
+		if (!$this->hasError($result)) {


since exec() is designed for methods that don't return a result set, I suggest changing the hasError($result) to hasError($this->pdoConnection). Do you think that would work?

tractorcow · 2017-02-15T20:50:15Z

I wrote some comments 6 days ago but forgot to submit review (so they were hidden). Sorry!

tractorcow · 2017-02-15T20:50:46Z

I think we need to use hasError($this->pdoConnection) instead of hasError($result) here.

ajoneil · 2017-02-15T20:58:32Z

Looks like you're right with checking the error on the connection, I'll fix that up.

chillu · 2017-02-28T09:26:06Z

Yay a wild Andrew appears!

tractorcow · 2017-03-01T01:06:12Z

Looks good; Let's see if travis wants to work today.

sminnee · 2017-04-16T04:18:00Z

@tractorcow are you happy with the latest incarnation of this?

tractorcow · 2017-04-17T22:19:33Z

Yes. :)

tractorcow suggested changes Feb 9, 2017

View reviewed changes

Remove negation of condition to make the code easier to read.

6af3289

dhensby reviewed Feb 15, 2017

View reviewed changes

tractorcow suggested changes Feb 15, 2017

View reviewed changes

Error should be checked on the db connection, not on the result

9492a8b

Merge branch '3.5' into dblib-pdo

66a9694

sminnee added this to the 3.5.4 milestone Apr 16, 2017

tractorcow approved these changes Apr 17, 2017

View reviewed changes

tractorcow merged commit 9e3df22 into silverstripe:3.5 Apr 17, 2017

kinglozzer mentioned this pull request Jun 7, 2018

FIX: Only set MYSQL_ATTR_INIT_COMMAND when using mysql driver (fixes #8103) #8147

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixes for using dblib PDO driver. #6612

Fixes for using dblib PDO driver. #6612

ajoneil commented Feb 9, 2017

tractorcow Feb 9, 2017 •

edited

Loading

tractorcow Feb 9, 2017

ajoneil Feb 9, 2017

ajoneil Feb 9, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

dhensby commented Feb 15, 2017

dhensby Feb 15, 2017

ajoneil Feb 15, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

tractorcow Feb 10, 2017

tractorcow commented Feb 15, 2017 •

edited

Loading

tractorcow commented Feb 15, 2017

ajoneil commented Feb 15, 2017

chillu commented Feb 28, 2017

tractorcow commented Mar 1, 2017

sminnee commented Apr 16, 2017

tractorcow commented Apr 17, 2017

Fixes for using dblib PDO driver. #6612

Fixes for using dblib PDO driver. #6612

Conversation

ajoneil commented Feb 9, 2017

tractorcow Feb 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dhensby commented Feb 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tractorcow commented Feb 15, 2017 • edited Loading

tractorcow commented Feb 15, 2017

ajoneil commented Feb 15, 2017

chillu commented Feb 28, 2017

tractorcow commented Mar 1, 2017

sminnee commented Apr 16, 2017

tractorcow commented Apr 17, 2017

tractorcow Feb 9, 2017 •

edited

Loading

tractorcow commented Feb 15, 2017 •

edited

Loading