Alexander Stelter – foo, bar, baz

Achtung:
Dieses Turorial bezieht sich auf eine veraltete Version von Doctrine und funktioniert vermutlich mit den neueren 1.x und späteren 2.x Releasen nicht mehr.

Heute starte ich meine Serie zum Thema ORM in PHP mit Doctrine.
Durch ORM ermöglicht man dem Programmierer den vollständigen objektorientierten Zugriff auf die Daten in der Datenbank und macht ihn somit unabhängig von der Speichern und verhindert somit auch die Verwendung von SQL. Das hat den Vorteil, dass man bei einem Wechsel des DBMS keine Querys anpassen muss (so denn das DBMS von dem ORM-Layer untersützt wird.

Doctrine ist eine in PHP5 programmierte Anwendung und ca. seit einem Jahr in Entwicklung. Da Doctrine dieses Jahr als Projekt bei Google Summer of Code antreten durfte, tut sich im Moment recht viel. Ich habe Doctrine seit der Revision 7xx verwendet und muss sagen, dass sich bis zur heutigen 2066 recht viel getan hat. Der erste Release-Candidate ist für Ende August angekündigt worden. Der Layer funktioniert großteils reibungslos, jedoch muss man bei Problemen auch hin und wieder mal in den Source schauen um zu verstehen, wieso etwas (noch) nicht funktioniert. Die Dokumentation ist zwar ausführlich, jedoch nicht so perfekt, als dass sie helfen könnte.

Heute machen wir einen kleinen Schnelleinstieg. Wir beginnen mit dem Aufbau der Db-Verbindung, Anlegen einer Doctrine-Db-Klasse, Einfügen von Datensätzen, Auslesen per Finder, Updaten, Auslesen per Query und Löschen. Die aktuellen Beispiele basieren auf der Revision 2066. Diese kann aus dem SVN-Repository von Doctrine ausgecheckt werden. Als Client verwende ich Tortoise SVN.
Steigen wir nun in unser Beispiel ein. Wir wollen in einer Datenbanktabelle Produkte speichern. In unserem Falle noch recht simpel in einer Tabelle. Als Verzeichnisstruktur legen wir folgendes an:

lib/external/Doctrine [Checkout-Verzeichnis für Doctrine]
lib/Data/Db [Ordner für die Db-Klassen]

Beginnen wir nun in unserer /index.php und binden dort zunächst Doctrine per Require ein. Danach muss der Autoloader von Doctrine registriert werden, damit die benötigten Unterklassen von Doctrine automatisch nachgeladen werden können. Danach können wir direkt eine Verbindnug zur Datenbank öffnen.

1
2
3
4

require_once ( './lib/Doctrine/lib/Doctrine.php' );
spl_autoload_register ( array( 'Doctrine' , 'autoload') );
 
$Connection = Doctrine_Manager::connection ('mysql://root:@localhost/doctrine');

Lassen wir uns diese nun per echo ausgeben, erhalten wir die Bestätigung, dass die Datenbankverbindung geöffnet wurde:

Doctrine_Connection object
State : open
Open Transactions : 0
Table in memory :
Driver name : mysql

Doctrine ist übrigens auch im Fehlerhandling komplett objektorientiert. Also werden keine Fehlermeldungen geworfen, sondern Exceptions. Diese müssen mittels try-catch-Block aufgefangen werden.

Jetzt haben wir Doctrine startklar gemacht, jedoch haben wir noch keine Datenbanktabelle, die wir verwenden können. Also legen wir uns mittels SQL folgende Tabelle an:

1
2
3
4
5
6

CREATE TABLE `products` (
`id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`name` VARCHAR( 255 ) NOT NULL ,
`description` TINYTEXT NOT NULL ,
`date_created` DATETIME NOT NULL
) ENGINE = MYISAM ;

Als nächstes legen wir die Doctrine-Db-Klasse an, mit der wir Doctrine sagen, wie die Tabelle aussehen soll, auf die wir zugreifen wollen. Eine Datenbankrelation entspricht also einer Doctrine-Klasse. Mittels hasColumn definieren wir die Spalten. Hier werden Name, Typ, Länge und Attribute angegeben. Die Klasse muss von der Doctrine-Klasse Doctrine_Record abgeleitet werden und sieht in unserem Falle so aus: (lib/Db/Product.php)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class
	Data_Db_Products
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('products');
 
        $this->hasColumn('id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true,
                                                   'autoincrement' => true));
		$this->hasColumn('name' , 'string' , 255 , array ('notnull' => true));
		$this->hasColumn('description' , 'string' , 3000 , array ('notnull' => true));
		$this->hasColumn('date_created' , 'timestamp' , null);
	}
 
}

Jetzt haben wir alle Werte gesetzt, um auf die Datenbank zugreifen zu können. Nun wollen wir mal ein Produkt anlegen und es direkt mittels der save()-Methode in die Datenbank speichern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

try
{
	$Product = new Data_Db_Products;
	$Product [ 'name' ] = 'My First Product';
	$Product [ 'description' ] = 'Product Product Product';
	$Product [ 'date_created' ] = date('Y-m-d H:i:s');
	$Product->save();
}
catch
(
	Exception $e
)
{
	var_dump($e->getMessage());
}

Geht bei dieser Operation etwas schief, so werden wir die Meldung von Doctrine im Catch-Block ausgegeben bekommen. Wir sehen, wir können ein Objekt vom Typ Data_Db_Products behandeln wie ein Array, da für diese Klassen SPL::ArrayAccess implementiert ist. Wir können natürlich anstatt der Array-Klammern auch die Objektpfeile benutzen $Product->name.
Nun können wir im PHPMyAdmin bereits sehen, dass ein Datensatz in der Datenbank angelegt worden ist. Fügen wir nun hinter dem Save folgendes ein:

1

echo $Product["id"];

wird uns die Id des gerade eingegebenen Produktes angezeigt. Dies können wir nun natürlich auch direkt auslesen. Für die Suche nach Primärschlüsselwerten bietet Doctrine eine Finder-Methode, auf die wie folgt zugegriffen werden kann:

1
2

$Product = $Connection->getTable('Data_Db_Products')->find ( 1 );
echo $Product["name"];

Das Ergebnis spricht für sich, es hat funktioniert:

My First Product

Jetzt wollen wir den gerade ermittelten Datensatz aktualisieren. Dazu reicht es, wenn wir die Werte, die wir ändern möchten via Array-Zugriff ändern und dann speichern. Das Mappen des Datensatzes übernimmt Doctrine. Jedoch dürfen wir nicht schreibend auf die Id zugreifen, das schützt uns vor ungewollten Aktionen:

1
2

$Product['name'] = 'My Second Product';
$Product->save()

Lesen wir dieses Produkt dann nochmal per finder neu ein, können wir sehen, dass die Änderung nicht nur in der Variable, sondern auch nach dem erneuten auslesen persistent gespeichert wurde:

My Second Product

Nun verschaffen wir uns mit folgendem Script mal ein paar Testdaten:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

for
(
	$i = 0; $i < 100; $i++
)
{
	try
	{
		$Product = new Data_Db_Products;
		$Product [ 'name' ] = 'Product ' . sprintf ( "%03d", $i );
		$Product [ 'description' ] = 'Product Product Product';
		$Product [ 'date_created' ] = date('Y-m-d H:i:s');
		$Product->save();
	}
	catch
	(
		Exception $e
	)
	{
		var_dump($e->getMessage());
	}
}

Jetzt möchten wir alle Produkte auslesen, welche eine Id zwischen 10 und 20 haben. Dazu verwenden wir einen Doctrine-Query, welcher dann eine Doctrine-Collection zurück gibt. Diese könnten wir dann mit einer Foreach-Schleife durchlaufen. Wir wollen aber zunächst nur auslesen und die Anzahl der Datensätze ausgeben:

1
2
3
4
5

$Query = new Doctrine_Query;
$Query->from ( 'Data_Db_Products p' );
$Query->where ( 'p.id < 20 AND p.id > 9' );
$Result = $Query->execute();
echo count($Result);

Das Ergebnis zeigt, dass wir Erfolg hatten:

10

Möchten wir anstatt einer Doctrine-Collection direkt ein Array zurück bekommen, um den Overhead, den die Objekte mit sich bringen, ein wenig einzuschränken tauschen wir den execute() Aufruf aus und erhalten folglich nur noch ein Array:

1

$Result = $Query->execute(array(1),Doctrine::FETCH_ARRAY);

Wir bleiben allerdings jetzt bei unserer Collection. Wir haben diese Objekte selektiert um sie zu löschen. Dies ist einfacher als man denkt, wie folgendes Beispiel zeigt:

1
2
3
4
5
6
7
8
9
10
11
12
13

$Query = new Doctrine_Query;
$Query->from ( 'Data_Db_Products p' );
$Query->where ( 'p.id < 20 AND p.id > 9' );
$Result = $Query->execute();
 
echo "<br />PRE-DELETE: ";
echo count($Result);
 
$Result->delete();
 
$Result = $Query->execute();
echo "<br />POST-DELETE: ";
echo count($Result);

Wir führen den Such-Query nach dem Löschen nochmal aus und sehen, dass wir nun 0 Datensätze haben die in unser Suchmuster passen. Das Löschen war also erfolgreich:

PRE-DELETE: 10
POST-DELETE: 0

Das soll es für heute auch gewesen sein. Ich werde die Reihe in unregelmäßigen Abständen fortsetzen. Es gibt noch viele spannende Themen wie 1:n- n:m-Beziehungen, Events … Ich freue mich über Kommentare und Meinungen und hoffe, dass ich mit diesen Beiträgen noch mehr Leute zur objektorientierten Programmierung und Doctrine bringen kann.

written by Alexander \\ tags: Doctrine, enterprise, mysql, orm, PHP