Call to undefined method PDO::execute()

Question 1

i'm trying to code a page login but i was stopper at this error

pliz tell me the wrong thing here

<?php
@session_start();
include("../../connexion/connexion.php");
class login_class {
        public $user;
        public $password;
        public $connexion;
    public function check_login() {
        try {
            $cn = new class_connect();
            $this->connexion = $cn->connect(null);
            $result = $this->connexion->execute("select * from user where username='$this->user' and password='$this->password'");

                        $data = $result->fetchAll(PDO::FETCH_OBJ);


            if (!empty($data[0]->id_user)) {
                return true;
            }else {
                return false;
            }
        }catch(PDOException $ex) {  
            echo $ex->getMessage();
        }
    }
    public function __construct($user) {
        if($user){
            $this->user = $user["username"];
            $this->password = $user["password"];
        }
    }

}
?>

Question 2

->execute() is for prepared statements. e.g.

$stmt = $dbh->prepare('some query here');
$stmt->execute();

You're trying to execute a query directly on the main DB object. For PDO, that means

 $dbh->exec('query goes here');

You really should look into prepared statements. You're vulnerable to SQL injection attacks as is, and since you're using PDO to begin with, it's basically unforgivable to NOT be writing safe queries.

Question 3

PDO does not escape the variables. The variables and the SQL command are transferred independently over the MySQL connection. And the SQL tokenizer (parser) never looks at the values. Values are just copied verbatim into the database storage without the possibility of ever causing any harm. That's why there is no need to marshall the data with prepared statements.

Note that this is mostly a speed advantage. With mysql_real_escape_string() you first marshall your variables in PHP, then send an inefficient SQL command to the server, which has to costly segregate the actual SQL command from the values again. That's why it's often said that the security advantage is only implicit, not the primary reason for using PDO.

If you concat the SQL command and don't actually use prepared statments (not good!), then yes, there still is an escape function for PDO: $pdo->quote($string)

Question 4

function __construct(){   $ingObject = new Ingredient();   }

ought to be

function __construct(){   $this->ingObject = new Ingredient();   }

In the first case you're setting a local variable, not a field, so it remains null. Then on the validateData you invoke a method on a null variable.

I'm assuming you snipped some code, because your Ingredient class doesn't make sense (there's a $validate variable there that isn't defined).

Question 5

Isn't the point of TDD that your testsuite fails while writing tests?

I guess your point is that it dies with a fatal error instead of just display the red "i failed" bar. Quite an interesting point, I'm doing TDD with phpunit but that never has bugged me at all.

The first thing that came do mind was --process-isolation.

Example:

Let's assume a test class that looks like this:

<?php

class fooTest extends PHPUnit_Framework_TestCase {

    public function testA() {
        $x = new a();
    }

    public function testB() {
        $this->assertTrue(true);
    }
}

using the normal runner phpunit test.php:

PHPUnit 3.5.12 by Sebastian Bergmann.

Fatal error: Class 'a' not found in /home/mcsvnls/mep.php on line 6

but when using the phpunit --process-isolation test.php switch it looks like this:

PHPUnit 3.5.12 by Sebastian Bergmann.

E.

Time: 1 second, Memory: 3.25Mb

There was 1 error:

1) fooTest::testA
RuntimeException: Fatal error: Class 'a' not found in /home/foo/mep.php on line 6

Call Stack:
    0.0005     102364   1. {main}() /home/foo/-:0
    0.0341    1768644   2. __phpunit_run_isolated_test() /home/foo/-:143
    [...........]

FAILURES!
Tests: 2, Assertions: 1, Errors: 1.

And now the second test gets executed and passes

Question 6

Well, at second glance your question looks more complex to be answered with just one link

How does php pdo's prepared statements prevent sql injection?

How can prepared statements protect from SQL injection attacks?

What are other pros/cons of using PDO?

Most interesting question.
A greatest PDO disadvantage is: it is peddled and propagated a silver bullet, another idol to worship.
While without understanding it will do no good at all, like any other tool.
PDO has some key features like

Database abstraction. It's a myth, as it doesn't alter the SQL syntax itself. And you simply can't use mysql autoincremented ids with Postgre. Not to mention the fact that switching database drivers is not among frequent developer's decisions.
Placeholders support, implementing native prepared statements or emulating them. Good approach but very limited one. There are lack of necessary placeholder types, like identifier or SET placeholder.
a helper method to get all the records into array without writing a loop. Only one. When you need at least 4 to make your work sensible and less boring.

Does using PDO reduce efficiency?

Again, it is not PDO, but prepared statements that reduces efficiency. It depends on the network latency between the db server and your application but you may count it negligible for the most real world cases.

Call to undefined method PDO::execute()

Answers

Example:

php,pdo