10.04.2018 Views

Doctrine_manual-1-2-en

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 8: Working with Models 109<br />

// test.php<br />

Listing<br />

8-36<br />

// ...<br />

$user = <strong>Doctrine</strong>_Core::getTable('User')->find(5);<br />

$user->GroupUser->remove(0)->remove(1);<br />

$user->save();<br />

This is due to a fact that the call to $user->GroupUser loads all Group links for giv<strong>en</strong> User.<br />

This can be time-consuming task if the User belongs to many Groups. Ev<strong>en</strong> if the user<br />

belongs to few groups this will still execute an unnecessary SELECT statem<strong>en</strong>t.<br />

Fetching Objects<br />

Normally wh<strong>en</strong> you fetch data from database the following phases are executed:<br />

1. S<strong>en</strong>ding the query to database<br />

2. Retrieve the returned data from the database<br />

In terms of object fetching we call these two phases the 'fetching' phase. <strong>Doctrine</strong> also has<br />

another phase called hydration phase. The hydration phase takes place wh<strong>en</strong>ever you are<br />

fetching structured arrays / objects. Unless explicitly specified everything in <strong>Doctrine</strong> gets<br />

hydrated.<br />

Lets consider we have Users and Phon<strong>en</strong>umbers with their relation being one-to-many. Now<br />

consider the following plain sql query:<br />

// test.php<br />

Listing<br />

8-37<br />

// ...<br />

$sql = 'SELECT u.id, u.username, p.phon<strong>en</strong>umber FROM user u LEFT JOIN<br />

phon<strong>en</strong>umber p ON u.id = p.user_id';<br />

$results = $conn->getDbh()->fetchAll($sql);<br />

If you are familiar with these kind of one-to-many joins it may be familiar to you how the basic<br />

result set is constructed. Wh<strong>en</strong>ever the user has more than one phon<strong>en</strong>umbers there will be<br />

duplicated data in the result set. The result set might look something like:<br />

index u.id u.username p.phon<strong>en</strong>umber<br />

0 1 Jack Daniels 123 123<br />

1 1 Jack Daniels 456 456<br />

2 2 John Beer 111 111<br />

3 3 John Smith 222 222<br />

4 3 John Smith 333 333<br />

5 3 John Smith 444 444<br />

Here Jack Daniels has two Phon<strong>en</strong>umbers, John Beer has one whereas John Smith has three.<br />

You may notice how clumsy this result set is. Its hard to iterate over it as you would need<br />

some duplicate data checking logic here and there.<br />

<strong>Doctrine</strong> hydration removes all duplicated data. It also performs many other things such as:<br />

1. Custom indexing of result set elem<strong>en</strong>ts<br />

2. Value casting and preparation<br />

3. Value assignm<strong>en</strong>t list<strong>en</strong>ing<br />

4. Makes multi-dim<strong>en</strong>sional array out of the two-dim<strong>en</strong>sional result set array, the<br />

number of dim<strong>en</strong>sions is equal to the number of nested joins<br />

----------------- Brought to you by

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!