Typically a PHP programmer will write his SQL query as a string and will execute it via mysql_query.

$sql = "SELECT * FROM my_table";
$resource = mysql_query($sql);

So eventually when you want to dump this “complex” query, or whatever query there is, you can simply “echo” it and see what’s its syntax.

// this query is WRONG because of the where clause
$sql = "SELECT * FROM my_table WHERE id = ";

// dump and debug the wrong query
die($sql);

// this line won't be executed
$resource = mysql_query($sql);

So far so good, but things appear to be a bit different when you start to work with Zend Framework. Higher levels of abstraction come with slightly more difficult ways to dump (debug) your SQL queries.

OK you’ve two options. Using Zend_Db_Select or … not.

Dump Zend_Db_Select Query

Debugging queries generated with Zend_Db_Select is as easy as the following snippet. Let’s say there’s a db table “users” and typically the model is called Users.

class Users extends Zend_Db_Table
{
	protected $_name = 'users';

	public function getSomeUsers()
	{
		$select = $this->select()
				->from(this->_name)
				->where('id > ');

		$rows = $this->fetchAll($select);
	}
}

Obviously this code is wrong, because the “where” clause is wrong and we don’t pass any values to it. So now the question is how can we dump this SQL. Well, since we use Zend_Db_Select, so the simplest way to dump the SQL is by calling __toString(). The code above will become as follows.

class Users extends Zend_Db_Table
{
	protected $_name = ‘users’;

	public function getSomeUsers()
	{
		$select = $this->select()
				->from(this->_name)
				->where('id > ');

		die($select->__toString());

		$rows = $this->fetchAll($select);
	}
}

That’s great, but how can we dump update/insert queries for instance?

Dump with Zend_Db_Profiler

The way you should dump insert or update queries is a bit different. You should use Zend_Db_Profiler, which is a more complex way to debug (profile) your queries. You can not only debug insert or update queries, of course, but any queries generated by the Zend_Db abstraction. Let’s see how.

Now from a controller perspective this model can be just called as:

$users = new Users();
$users->update(array('name' => 'my name'), 'id =');

Obviously this code is wrong, again because of the where clause and now the question is how we can debug the generated SQL. The answer is: using Zend_Db_Profiler. Looking back again to the model, this should look like this.

class Users extends Zend_Db_Table
{
	protected $_name = ‘users’;

	public function updateSomeUsers()
	{
		// first enable the profiler
		$this->getProfiler()->setEnabled(true);

		// try to execute
		$this->update(array('name' => 'my name'), 'id = ');

		// dump the SQL
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQuery());

		// don't forget to disable the profiler is
		// you don't need it anymore
		$this->getProfiler()->setEnabled(false);
	}
}

The thing is that since Zend_Db is using prepared statements, the last row (the one with the Zend_Debug::…) will dump something like the following line.

UPDATE `users` SET `name` = ? WHERE (id =)

So as you can see, actually here you don’t see the name’s value, which should be “my name”. To see this you should call getQueryParams().

class Users extends Zend_Db_Table
{
	protected $_name = 'users';

	public function updateSomeUsers()
	{
		// first enable the profiler
		$this->getProfiler()->setEnabled(true);

		// try to execute
		$this->update(array('name' => 'my name'), 'id = ');

		// dump the SQL
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQuery());
		Zend_Debug::dump($this->getProfiler()->getLastQueryProfile()->getQueryParams());

		// don't forget to disable the profiler is
		// you don't need it anymore
		$this->getProfiler()->setEnabled(false);

Now the debug info will be something like this.

UPDATE `users` SET `name` = ? WHERE (id =)
array
	1 => string 'my name' (length 7)

Calling this from the controller there are some changes. Take a look at the example bellow.

$users = new Users();

// enable the profiler
$users->getAdapter()->getProfiler()->setEnabled(true);

// execute (or at least try to)
$users->update(array('name' => 'my name'), 'id =');

// debugdump the SQL
Zend_Debug::dump($users->getAdapter()->getProfiler()->getLastQueryProfile()->getQuery());
Zend_Debug::dump($users->getAdapter()->getProfiler()->getLastQueryProfile()->getQueryParams());

// don't forget to disable the profiler is
// you don't need it anymore
$users->getAdapter()->getProfiler()->setEnabled(false);

In this case you should use the longer model_name->getAdapter()

What is really handy in Zend Framework is that you can fetch the entire row set with the fetchAll() method. It comes with some parameters that you can use for limiting the result or ordering, but in general you can use it without specifying parameters. Let say this is the model:

getAdapter()->query($query);
	
		return $rs->fetchAll();
		
	}
	
}

You can simply return the row set with the fetchAll() method as described in the example, but what if you have to loop through the rows and to modify somehow the values?

Fetching a Row

By simply change the code like so:

class User extends Zend_Db_Table
{
		
	public function listAll()
	{
		$query = "SELECT * FROM user";
	
		// exec query
		$rs = $this->getAdapter()->query($query);
	
		// fetch
		$list = array();
		while ($row = $rs->fetch()) {
			// removing the password column value
			$row['password'] = '';
			
		    $list[] = $row;
		}
	
		return $list;
	}
}

you can modify the rows and you’ll have the same result.

First of all let me explain what is the task. If there’s a select menu with several options, each of which are with a given value attribute, the task is to get the text into the option tag, and not that of the value attribute.

In that scenario let’s assume that we have the following HTML:

    value 1
    value 2

Note that in the official jQuery doc page, the selector is described in the same context, but with a different markup:

    value 1
    value 2

than the jQuery snippet looks like that:

$(document).ready(function() {
    $("#my-select").change(function() {
        alert($(this).val());
    });
});

Here’s interesting to note that there’s no value attribute set to the options, thus the selection of an element is correct and the returned value is correct. The problem is that this code doesn’t work correctly once you’ve a different value attribute, from the value enclosed into the option tag. In our case we’ve the markup shown on the first code snippet and we’d like to get the “value 2” string instead of “2”.

Source Code

    value 1
    value 2

$(document).ready(function() {
    $("#my-select").change(function() {
        alert($(this).val());
    });
});

Solution

Finally the solution, is pretty simple and clear, but this time is not to so “native” and it’s definitely something you couldn’t expect! The only thing you’ve to do is to change the selector!

$(document).ready(function() {
    $("#my-select).change(function() {
        alert($('#my-select option:selected').html());
    });
});