Completed
Pull Request — master (#31)
by Damian
06:15
created

SQLServerQuery   A

Complexity

Total Complexity 13

Size/Duplication

Total Lines 82
Duplicated Lines 0 %

Coupling/Cohesion

Components 1
Dependencies 1

Importance

Changes 0
Metric Value
wmc 13
c 0
b 0
f 0
lcom 1
cbo 1
dl 0
loc 82
rs 10

5 Methods

Rating   Name   Duplication   Size   Complexity  
A __construct() 0 5 1
A __destruct() 0 6 2
A seek() 0 8 2
A numRecords() 0 13 3
B nextRecord() 0 23 5
1
<?php
2
3
namespace SilverStripe\MSSQL;
4
5
6
use SilverStripe\ORM\Connect\SS_Query;
7
use DateTime;
8
9
10
/**
11
 * A result-set from a MSSQL database.
12
 * 
13
 * @package mssql
14
 */
15
class SQLServerQuery extends SS_Query
16
{
17
18
    /**
19
     * The SQLServerConnector object that created this result set.
20
     * 
21
     * @var SQLServerConnector
22
     */
23
    private $connector;
24
25
    /**
26
     * The internal MSSQL handle that points to the result set.
27
     * 
28
     * @var resource
29
     */
30
    private $handle;
31
32
    /**
33
     * Hook the result-set given into a Query class, suitable for use by sapphire.
34
     * @param SQLServerConnector $connector The database object that created this query.
35
     * @param resource $handle the internal mssql handle that is points to the resultset.
36
     */
37
    public function __construct(SQLServerConnector $connector, $handle)
38
    {
39
        $this->connector = $connector;
40
        $this->handle = $handle;
41
    }
42
43
    public function __destruct()
44
    {
45
        if (is_resource($this->handle)) {
46
            sqlsrv_free_stmt($this->handle);
47
        }
48
    }
49
50
    public function seek($row)
51
    {
52
        if (!is_resource($this->handle)) {
53
            return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type declared by the abstract method SilverStripe\ORM\Connect\SS_Query::seek of type array.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
54
        }
55
56
        user_error('MSSQLQuery::seek() not supported in sqlsrv', E_USER_WARNING);
57
    }
58
59
    public function numRecords()
60
    {
61
        if (!is_resource($this->handle)) {
62
            return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type declared by the abstract method SilverStripe\ORM\Connect\SS_Query::numRecords of type integer.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
63
        }
64
65
        // WARNING: This will only work if the cursor type is scrollable!
66
        if (function_exists('sqlsrv_num_rows')) {
67
            return sqlsrv_num_rows($this->handle);
68
        } else {
69
            user_error('MSSQLQuery::numRecords() not supported in this version of sqlsrv', E_USER_WARNING);
70
        }
71
    }
72
73
    public function nextRecord()
74
    {
75
        if (!is_resource($this->handle)) {
76
            return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type declared by the abstract method SilverStripe\ORM\Connect\SS_Query::nextRecord of type array.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
77
        }
78
79
        if ($data = sqlsrv_fetch_array($this->handle, SQLSRV_FETCH_ASSOC)) {
80
            // special case for sqlsrv - date values are DateTime coming out of the sqlsrv drivers,
81
            // so we convert to the usual Y-m-d H:i:s value!
82
            foreach ($data as $name => $value) {
83
                if ($value instanceof DateTime) {
84
                    $data[$name] = $value->format('Y-m-d H:i:s');
85
                }
86
            }
87
            return $data;
88
        } else {
89
            // Free the handle if there are no more results - sqlsrv crashes if there are too many handles
90
            sqlsrv_free_stmt($this->handle);
91
            $this->handle = null;
92
        }
93
94
        return false;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return false; (false) is incompatible with the return type declared by the abstract method SilverStripe\ORM\Connect\SS_Query::nextRecord of type array.

If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.

Let’s take a look at an example:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
95
    }
96
}
97