Im Vergleich zu vorherigen Distributionen wie YOXOS und Easy Eclipse kann die PDT Distribution an vielen Stellen Punkte sammeln. Vor allem das verbesserte Outline für Klassen und vererbte Klassen und das bessere Autocomplete von Klassen, Variablen und sogar Klassen-Konstanten können sich sehen lassen. Ich arbeite mitlerweile vorzugsweise mit PDT, weil mir diese Eigenschaften zusätzlich Zeit einsparen und die Effizienz beim Arbeiten erhöht.

Ein kleiner Schönheitsfehler ist aber dennoch enthalten. Das Subclipse Plugin wollte bei mir nicht so wirklich installiert werden. Zunächst fehlten einige Core-Plugins, die Voraussetzung für das Subclupse Plugin sind und als diese installiert waren, fehlten noch einige andere Dinge. Ich hab’s nachher dann erstmal aufgegeben, weil ich nicht mehr allzu viel Zeit dazu hatte. Es gibt ja glücklicherweise Stand-Alone Anwendungen wie RapidSVN mit denen man dann dennoch ein SVN Repoisitory bedienen kann. Es ist zwar nicht ganz so aus einem Guss, aber für die tägliche Arbeit auch nicht hinderlich.

Wenn ich’s doch schaffe, das Subclipse Plugin installiert zu bekommen, werde ich das natürlich mitteilen und auch beschreiben, wie’s funktioniert. Falls jemand anders das schonmal gelöst haben sollte, bitte kurz eine Nachricht hinterlassen – das interessiert mich brennend .

Weiterhin fiebert man im Hause Doctrine bereits dem Release von PHP 5.3 entgegen, da man danach die Klassen-Infrastruktur von Doctrine auf Namespaces umstellt und somit eine weitere Modularisierung erreicht.

Ich habe leider im Moment keine Gelegenheit eine der aktiven Branches produktiv zu verwenden, werde aber wahrscheinlich in naher Zukunft wieder Gelegenheit haben mit einer neueren Version zu arbeiten. Ich kann allerdings auch sagen, dass die älteren Versionen auch im Produktivbetrieb doch schon recht stabil sind (so man sie dann mal ans Laufen bekommen hat) .

Für interessierte Leser kann ich auch die diversen Mailinglisten empfehlen. Hier wird munter über die Weiterentwicklung, Refactoring und Probleme diskutiert. Ich halte weiterhin an Doctrine fest, es ist ein wirklich tolles Tool wenn man objektorientiert Programmieren will und sein Datenmodell über einen ORM-Layer abstrahieren will. Man sollte trotzdem bedenken, dass eine solche Struktur nicht gerade für schwache Live-Maschinen gedacht ist – ich gehe hier von einem High-Traffic-Projekt aus. Für das Blog um die Ecke oder die Webvisitenkarte sollte ein normales Web-Paket durchaus ausreichen . Beziehen kann man Doctrine aus dem offiziellen SVN Repository.

Just heute mußte ich feststellen, dass die Rückwärtskompatibilität schon gelitten hat, denn nach einem Update auf die neuste Revision funktionierte die Anwendung nicht mehr. Ich habe es mir erstmal gespart das zu debuggen und die alte Version zurückgespielt und hebe mir diesen Spaß mal für später auf. Im Prinzip finde ich das nicht schlimm, denn man setzt diese Version ja auf eigene Gefahr ein, jedoch dann einen Rückschritt von einem lang angekündigten RC auf eine Beta zu machen finde ich doch merkwürdig, war da jemand zu voreilig? Das hält mich natürlich nicht davon ab Doctrine weiter zu verwenden ..

Was ich noch erwähnen will, dass ich sehr begeistert von der neuen Webseite bin, die offenkundig auf Symfony basiert. Endlich gibt es eine Api-Doku und ein neues Manual, mit dem man besser arbeiten kann, wie ich finde. Mal schauen, wie es weiter geht ..

In diesem Beispiel nehmen wir einen Kategoriebaum, in den wir die Produkte aus den vorherigen Beispielen einordnen könnten. Ich lege den Fokus aber nur auf den Baum und die Kategorien, die Verknüpfung zwischen Kategorie und Produkt stellt dann später nur noch eine 1:n-Beziehung dar, falls Verständnisprobleme auftreten, kann ich das gerne im Einzelfall per E-Mail schildern .Legen wir also zunächst, wie bei den anderen Beispielen auch, die Datenbanktabellen mittels SQL an und danach die PHP Klassen.

Die SQL Querys sind eigentlich nicht spektakulär. Zur Tabelle cattree sei zu sagen, dass die Felder lft, rgt, level und root_id von Doctrine selber gesetzt werden und wir uns nicht drum kümmern müssen. lft und rgt geben die Range der jeweiligen Einträge an. Die root_id verwaltet die einzelnen Bäume. Wir können mittels Doctrine in einer Tabelle mehrere verschiedene Bäume verwalten. Der Flexibilität halber verwende ich das immer direkt. Dann kann man später immernoch einen Baum hinzufügen, wenn nötig. Hier also die SQL Querys:

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

CREATE TABLE `cat` (
`id` BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`name` VARCHAR( 255 ) NOT NULL
) ENGINE = MYISAM ;
 
 
 
CREATE TABLE `cattree` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `lft` bigint(20) NOT NULL,
  `rgt` bigint(20) NOT NULL,
  `category_id` bigint(20) NOT NULL,
  `level` bigint(20) NOT NULL,
  `root_id` bigint(20) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM;

Kommen wir nun zu den Doctrine Records. Die Kategorie-Tabelle ist auch unspektakulär. Man kann natürlich den Namen auch direkt im Baum speichern, aber über eine zusätzliche Verknüpfung ist das ganze noch ein wenig flexibler .

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

class
	Data_Db_Cat
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('cat');
 
        $this->hasColumn('id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true,
                                                   'autoincrement' => true));
		$this->hasColumn('name' , 'string' , 255 , array ('notnull' => true));
	}
 
	public function setUp
	(
	)
	{
	}
 
}

Kommen wir nun zum Baum selbst. Hier sehen wir kleine Differenzen zu den “normalen” Records. Wir müssen hier nur die ID, category_id und root_id selber definieren. Wenn wir nur einen Baum verwalten möchten, können wir die root_id auch weglassen. Zusätzlich sagen wir der Klasse, dass sie als NestedSet fungieren soll (actAs()) und übergeben, dass wir mehrere Bäume verwalten wollen und wie die root-Ebene heißen soll. Zu guterletzt verknüpfen wir den Baum mit der Kategorie und fertig ist das NestedSet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class
	Data_Db_Cattree
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('cattree');
 
        $this->hasColumn('id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true,
                                                   'autoincrement' => true));
		$this->hasColumn('category_id' , 'integer' , 8 , array ('notnull' => true));
        $options = array('hasManyRoots' => true, 'rootColumnName' => 'root_id');
        $this->actAs('NestedSet', $options);
	}
 
	public function setUp
	(
	)
	{
        $this->hasMany('Data_Db_Cat', array('local' => 'category_id',
                                    'foreign' => 'id'));
	}
 
}

Legen wir also nun einen neuen Root-Node an. Dazu müssen wir zunächst eine neue Kategorie anlegen, diese jedoch nicht speichern. Beim Übergeben eines Records an den Baum wird eine Autosave-Methode aufgerufen, die das Speichern für uns übernimmt.

1
2

$Category = new Data_Db_Cat;
$Category["name"] = 'Meine RootNode';

Nachdem wir eine Kategorie angelegt haben, legen wir einen Record in der Tree-Tabelle an und weisen ihr den betreffenden Eintrag zu, auch hier müssen wir nicht speichern.

1
2

$RootNode = new Data_Db_Cattree;
$RootNode->Data_Db_Cat = $Category;

Damit das ganze jetzt aber auch was mit unserem Baum zu tun hat, müssen wir nun die NestedSet-Struktur anlegen, dazu holen wir uns erstmal das Tabellen-Objekt mittels getTable() und führen darauf dann ein getTree() aus. Dann können wir mittels createRoot() den Knoten anlegen und speichern.

1
2

$Tree = $Connection->getTable('Data_Db_Cattree')->getTree();
$Tree->createRoot($RootNode);

Jetzt wollen wir mal ein paar Einträge in den Baum schreiben und diese danach wieder auslesen. Dazu müssen wir uns zunächst den Baum abholen, bzw. den Root-Knoten. Dieser hat die Id 1, das haben wir uns gemerkt.

1

$RootNode = $Connection->getTable('Data_Db_Cattree')->find(1);

Für das Arbeiten auf dem Baum sind hier nicht die Kategorie-Ids ausschlaggebend, sondern die Node-Ids. Man kann aber über eine Querverknüpfung natürlich von den Kategorien auf die Node-Ids kommen.

Jetzt wollen wir 10 Ebenen mit jeweils 5 Unterebenen einziehen. Dazu verwenden wir zwei verschachtelte For-Schleifen. Das Konzept bleibt gleich: Kategorie anlegen, Node-Eintrag anlegen, einfügen. Hier verwenden wir aber zum Einfügen nicht mehr createRoot() sondern insertAsFirstChildOf. Dies wird auf den Node-Record ausgeführt. Hier wird zusätzlich noch eine Zwischenebene verwendet. Zunächst haben wir nur den Record. Mittels getNode() auf den Record sagen wir, dass wir die Baum-Funktionalitäten in Anspruch nehmen wollen und wandeln den Record in einen NestedSet Record um und fügen diesen dann ein:

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

for
(
	$i = 0; $i < 10; $i++
)
{
	$Category = new Data_Db_Cat;
	$Category["name"] = 'Ebene ' . $i . '-1';
 
	$NodeRecord = new Data_Db_Cattree;
	$NodeRecord->Data_Db_Cat = $Category;
 
	$NodeRecord->getNode()->insertAsFirstChildOf($RootNode);
 
	for
	(
		$x = 0; $x < 5; $x++
	)
	{
		$InnerCategory = new Data_Db_Cat;
		$InnerCategory["name"] = 'Ebene ' . $i . '-2-' . $x;
 
		$InnerNode = new Data_Db_Cattree;
		$InnerNode->Data_Db_Cat = $InnerCategory;
 
		$InnerNode->getNode()->insertAsFirstChildOf($NodeRecord);
	}
}

Nun wollen wir auf dem Baum lesen. Mittels fetchBranch können wir an einem bestimmten Punkt einsteigen und ab da alle Kindelemente auslesen. Das ist für den Direkteinstieg in den Baum ziemlich praktisch und es ist keine Rekursion nötig. Das komplette Ausgeben des Baums lösen wir gleich mit einer Funktion (normalerweise ist das ja teil einer Klasse, aber in unserem simplen Beispiel ist es nur eine rekursive Funktion).

Mittels getLevel() auf einen Node, sind wir übrigens immer in der Lage die Tiefe des aktuellen Nodes auszugeben. Natürlich gibt es auch Funktionen, um von einem Node aufwärts zu laufen, dazu gibt es z.B. getParent(), das aber nur am Rande. Schauen wir uns nun das Auslesen eines Teilbaumes an:

1
2
3
4
5
6
7
8
9
10
11

$Branch = $Connection->getTable('Data_Db_Cattree')->getTree()->fetchBranch(14);
 
foreach
(
	$Branch as $Record
)
{
	$Node = $Record->getNode();
 
	echo str_repeat ( ' - ', $Node->getLevel()  ) . ' ' .$Record->Data_Db_Cat->name . '<br />';
}

Das Ergebnis zeigt, dass alles korrekt funktioniert:

- Ebene 2-1
- – Ebene 2-2-4
- – Ebene 2-2-3
- – Ebene 2-2-2
- – Ebene 2-2-1
- – Ebene 2-2-0

Jetzt gehen wir den Baum einmal mit einer rekursiven Funktion durch. Dafür holen wir uns zunächst auch wieder den Root-Node herraus:

1

$RootNode = $Connection->getTable('Data_Db_Cattree')->find(1);

Anschließend rufen wir unsere Funktion printTree auf und übergeben den Knoten. PHP arbeitet hier speicherschonend mit Referenzen. Der übergebene Node ist nur ein Doctrine-Record, also muss in der Funktion zunächst auch wieder ein getNode() folgen. Danach prüfen wir, ob Kindelemente vorhanden sind (hasChildren()) und geben diese aus. Dann prüfen wir, ob die jeweiligen Kindelemente noch Unterelemente haben und rufen die Funktion anschließend mit diesem Knoten neu auf, eigentlich ganz einfach .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

function printTree
(
	$Record
)
{
	$Node = $Record->getNode();
	if
	(
		$Node->getLevel() == 0
	)
	{
		echo str_repeat ( ' - ', $Node->getLevel()  ) . ' ' .$Record->Data_Db_Cat->name . '<br />';
	}
	if
	(
		$Node->hasChildren()
	)
	{
		foreach
		(
			$Node->getChildren() as $Child
		)
		{
			$ChildNode = $Child->getNode();
			echo str_repeat ( ' - ', $ChildNode->getLevel()  ) . ' ' .$Child->Data_Db_Cat->name . '<br />';
			if
			(
				$ChildNode->hasChildren()
			)
			{
				printTree($Child);
			}
		}
	}
}
 
$RootNode = $Connection->getTable('Data_Db_Cattree')->find(1);
printTree($RootNode);

An der Ausgabe sehen wir, dass alles richtig gelaufen ist (gekürzt, weil zu lang )

Meine RootNode
- Ebene 9-1
- – Ebene 9-2-4
- – Ebene 9-2-3
- – Ebene 9-2-2
- – Ebene 9-2-1
- – Ebene 9-2-0
- Ebene 8-1
- – Ebene 8-2-4
- – Ebene 8-2-3
- – Ebene 8-2-2
- – Ebene 8-2-1
- – Ebene 8-2-0
- Ebene 7-1
- – Ebene 7-2-4
- – Ebene 7-2-3
- – Ebene 7-2-2
- – Ebene 7-2-1
- – Ebene 7-2-0

Allerdings sollte man dazu sagen, dass die Sortierung bei diesem Konzept ein wenig problematisch ist, eine Lösung gibt es zwar dafür, aber die würde zu weit führen. Desweiteren kann ich einen Blick in die Doku empfehlen, wo noch weitere tolle Funktionen des NestedSets erklärt sind. (Löschen, verschieben, einfügen an bestimmten Punkten etc.).

Man sollte sich allerdings nicht einbilden, dass NestedSets ultra schnell sind. Hier ist die Flexibilität auf Kosten der Performance entstanden. Durch die Verschachtelung und die Struktur sind Schreiboperationen sehr rechenintensiv, da die Grenzen neu berechnet werden müssen, jedoch ist so ein Kategoriebaum in Kombination mit memcached (welcher auch bereits in Doctrine implementiert ist und ein Treiber vorhanden ist) doch recht gut benutzbar, eine Empfehlung an alle, die Kategoriebäume mit beliebiger Größe verwalten müssen. Für Leseoperationen ist das Cachen natürlich praktisch, für Schreiboperationen löst es die Probleme nicht, jedoch werden die Tabellen nicht gelockt, wenn geschrieben wird, da das Lesen über den Cache erfolgt.

Fragen beantworte ich natürlich gerne per Mail oder in den Kommentaren .

Wie ich finde ein guter Schritt in die richtige Richtung. Meiner Meinung nach macht PHP mehr und mehr Schritte um sich endlich auch im Enterprise-Bereich festzusetzen und da kommt eine Unterstützung in dieser Form schon ganz recht . Ich werde mir das Teil auf jeden Fall mal ansehen und ggf. von Easy-Eclipse auf diese neue Entwicklungsumgebung umsteigen.

Wie ich finde eine sehr respektable Leistung. Ich verfolge das Doctrine Projekt bereits seit der Revision 7xx und bin überrascht, welche Fortschritte ein Projekt in so kurzer Zeit machen kann. Natürlich wurde der Entwicklungsfortschritt von Doctrine sehr durch das Google Summer of Code Projekt im diesen Jahr begünstigt, jedoch muss man auch sagen, dass nicht nur Zeit und Geld notwendig ist, um eine Software stabil zu machen, sondern auch Entwicklergeist und Können und das haben die Entwickler von Doctrine auf jeden Fall schon recht früh bewiesen. Ich kann aus eigener Erfahrung sagen, dass das Entwickeln mit Doctrine zwar ab und an doch noch einiges an Nerven kostet, aber dann, wenn man durchgestiegen ist, doch recht viel Freude macht.

Schauen wir mal wie es weiter geht

Sie sind ein einfaches Instrument, die auch bei vielen DBMS durch Trigger abgebildet sind. Ein praktisches Beispiel schauen wir uns nun einmal an. Wir haben ja eine Produkt-Tabelle und Klasse, hier wollen wir nun eine User-Id speichern, damit wir wissen, welcher User ein Produkt angelegt hat. Zusätzlich möchten wir einen aggregierten Counter für jeden User haben, damit wir nicht bei jedem Request seines Profils alle Produkte summieren müssen, um herrauszufinden, wie viele Produkte ein User angelegt hat. Dies soll natürlich nicht explizit geschehen müssen. Wir möchten, dass einem User automatisch ein Produkt “gutgeschrieben” wird, sobald er es anlegt, und es abgezogen wird, wenn er das Produkt löscht.

Hierzu legen wir ein Feld “product_count” an, welches beim User selbst abgelegt wird. Beginnen wir nun mit dem Anlegen der User-Klasse und Datenbank-Tabelle:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

class
	Data_Db_Users
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('users');
 
        $this->hasColumn('id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true,
                                                   'autoincrement' => true));
		$this->hasColumn('username' , 'string' , 255 , array ('notnull' => true));
		$this->hasColumn('firstname' , 'string' , 255 , array ('notnull' => true));
		$this->hasColumn('lastname' , 'string' , 255 , array ('notnull' => true));
		$this->hasColumn('password' , 'string' , 255 , array ('notnull' => true));
		$this->hasColumn('product_count' , 'integer' , 8 , array ('default' => 0));
	}
 
	public function setUp
	(
	)
	{
        $this->hasMany('Data_Db_Products', array('local' => 'id',
                                    'foreign' => 'users_id'));
	}
 
}

Die Tabelle Verknüpfen wir direkt über die users.id über die users_id mit der Produkt-Tabelle. Bevor wir uns aber genauer der Produktkklasse widmen, müssen wir noch die Datenbanktabelle mittels SQL in der Datenbank anlegen:

1
2
3
4
5
6
7
8
9

CREATE TABLE `users` (
  `id` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `username` varchar(255) collate latin1_general_ci NOT NULL,
  `firstname` varchar(255) collate latin1_general_ci NOT NULL,
  `lastname` varchar(255) collate latin1_general_ci NOT NULL,
  `password` varchar(255) collate latin1_general_ci NOT NULL,
  `product_count` bigint(20) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM

Ist dies nun gemacht, legen wir eine Rückverknüpfung für die Produkt-Tabelle an. Hierzu fügen wir zunächst das Feld “users_id” in die Klasse Data_Db_Products ein. Dazu muss die folgende Zeile in die Table-Definition eingefügt werden:

1

$this->hasColumn('users_id' , 'integer' , 8 , array ('notnull' => true));

Desweiteren wollen wir die Verknüpfung zur User-Tabelle realisieren, dies tun wir mit folgender Definition in der allerseits bekannten setUp-Methode:

1
2

        $this->hasOne('Data_Db_Products', array('local' => 'users_id',
                                    'foreign' => 'id'));

Nun sollte noch das Feld in die Tabelle ausgeführt werden, dazu reicht ein Alter-Table-Befehl:

1

ALTER TABLE `products` ADD `users_id` BIGINT NOT NULL AFTER `id` ;

Wenden wir uns nun den Event-Listenern zu. Doctrine unterstützt eine Reihe von Listenern. Eine vollständige Liste findet man im Manual. Ich beschränke mich in meinem Beispiel auf zwei Record-Hooks. Es gibt noch diverse andere Möglichkeiten, die im Manual beschrieben sind. leider mußte ich feststellen, dass zwischen einigen Revisions die separaten Listener-Klassen nicht mehr funktionierten, vielleicht ist dies ja mitlerweile wieder der Fall. Wir beschränken uns auf einen postInsert und einen postDelete-Hook. Im Manual findet sich auch ein Hinweis, dass dieser Bereich gerade under heavy Construction ist, es empfielt sich also öfters mal ins Manual zu sehen.

Erstellen wir nun zunächst einen neuen User und speichern diesen persistent in die Datenbank. Hierbei kommen bisher keine Techniken zum Einsatz, die in vorherigen Einträgen nicht schon beschrieben worden wären. Der Vollständigkeit halber, hier aber nochmal ein vollständiges Beispiel:

1
2
3
4
5
6

$Users = new Data_Db_Users;
$Users["username"] = 'User01';
$Users["firstname"] = 'John';
$Users["lastname"] = 'Doe';
$Users["password"] = md5('test12345');
$Users->save();

Jetzt legen wir einen postInsert Listener an, der reagiert, NACHDEM ein Eintrag neu eingefügt wurde, wir erhöhen damit den Counter des Produkts und speichern es wieder. Das Gegenstück dazu heißt postDelete und wird nach dem Löschen eines Produkts ausgeführt und macht genau das Gegenstück von dem, was postInsert macht. Fügen wir nun diese beiden Methoden in die Produkt-Datenbank-Klasse ein:

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

	public function postInsert
	(
	)
	{
		$Users = $GLOBALS ["Connection"]->getTable('Data_Db_Users')->find($this["users_id"]);
		$Users["product_count"] = $Users["product_count"]+1;
		$Users->save(); 
	}
 
	public function postDelete
	(
	)
	{
		$Users = $GLOBALS ["Connection"]->getTable('Data_Db_Users')->find($this["users_id"]);
		$Users["product_count"] = $Users["product_count"]-1;
		$Users->save(); 
	}

Dies testen wir nun mit dem folgenden Code:

1
2
3
4
5
6

$Products = new Data_Db_Products;
$Products["name"] = 'MyProduct01';
$Products["users_id"] = $Users["id"];
$Products->save();
 
$Products->delete();

Wir fügen nun ein Produkt ein und löschen es danach wieder. Das bedeutet, dass der Counter “product_count” weiterhin bei 0 stehen bleibt. Kommentieren wir nun das Delete aus, wird der Counter hochgezählt. Wir haben also alles richtig gemacht .
Weitere Einsatzzwecke für die Listener sind weit gesteckt. Von History-Generierung über Datumsaktualisierung kann man einiges machen, da bleibt der eigenen Phantasie und Logik keine Grenze gesetzt, viel Spaß beim Ausprobieren.

Ich kann jetzt noch nicht konkret sagen, zu welchem Doctrine-Thema die Reihe fortgesetzt wird, aber sie wird fortgesetzt .

Steigen wir aber nun in die Entwicklung der Doctrine Klassen ein.Legen wir nun zunächst die Klasse für unseren Point of Sale an. Das ist eine einfache Doctrine-Klasse, wie wir sie so kennen. Eine Besonderheit dabei ist der neue Relationstyp:

1
2
3

         $this->hasMany('Data_Db_ProductsVariations', array('local' => 'pos_id',
                                    'foreign' => 'products_variations_id',
                                    'refClass' => 'Data_Db_ProductsVariations2pos'));

Hier sehen wir die Besonderheit der Relation. Wir geben also nicht direkt den Schlüssel der fremden Tabelle an (in diesem Falle wäre es auch einfach nur id) sondern den Namen des Fremdschlüssels, wie er in der Verknüpfungstabelle heißt. Ebenso geben wir für die eigene Tabelle nicht die id an, sondern auch den Namen des Schlüssels, wie er in der Verknüpfungstabelle lautet. Zu guterletzt benennen wir die Verknüpfungsklasse noch über refClass. Im Ganzen sieht die Klasse dann so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class
	Data_Db_Pos
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('pos');
 
        $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);
	}
 
	public function setUp
	(
	)
	{
        $this->hasMany('Data_Db_ProductsVariations', array('local' => 'pos_id',
                                    'foreign' => 'products_variations_id',
                                    'refClass' => 'Data_Db_ProductsVariations2pos'));
	}
 
}

Um die Verknüpfung nicht zu einseitig zu gestalten, fügen wir in die Data_Db_ProductsVariations noch die Gegenverknüpfung ein:

1
2
3

        $this->hasMany('Data_Db_Pos', array('local' => 'products_variations_id',
                                    'foreign' => 'pos_id',
                                    'refClass' => 'Data_Db_ProductsVariations2pos'));

Nun haben wir Anwendungsseitig schonmal die halbe Miete erledigt, jetzt legen wir zunächst mal die Tabelle in der Datenbank an. Dazu verwenden wir folgenden SQL-Query:

1
2
3
4
5
6
7

CREATE TABLE `pos` (
`id` bigint( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
`name` varchar( 255 ) COLLATE latin1_general_ci NOT NULL ,
`description` tinytext COLLATE latin1_general_ci NOT NULL ,
`date_created` datetime NOT NULL ,
PRIMARY KEY ( `id` )
) ENGINE = MYISAM DEFAULT CHARSET = latin1 COLLATE = latin1_general_ci;

Jetzt müssen wir als nächstes, bevor wir mit den Daten arbeiten können, die Verknüpfungstabelle realisieren. Dazu legen wir eine “normale” Doctrine-Klasse an, die komplett ohne Relationen auskommt, da die Verknüpfungen über die Entitäten selbst realisiert werden. Die Klasse und somit auch die Tabelle, besteht also auch nur aus zwei Spalten und sieht folgendermaßen aus:

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

class
	Data_Db_ProductsVariations2pos
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('products_variations2pos');
 
        $this->hasColumn('products_variations_id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true));
        $this->hasColumn('pos_id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true));
	}
}

Via Sql legen wir dann noch die Tabelle in der Datenbank an. Anschließend sind wir startklar und können Daten einfügen und auslesen:

1
2
3
4
5

CREATE TABLE `products_variations2pos` (
`products_variations_id` BIGINT UNSIGNED NOT NULL ,
`pos_id` BIGINT UNSIGNED NOT NULL ,
PRIMARY KEY ( `products_variations_id` , `pos_id` )
) ENGINE = MYISAM ;

Jetzt wollen wir erstmal ein Produkt auslesen, damit wir weiter arbeiten können, dies erledigen wir per Finder. Wir nehmen das Beispiel, dass wir Coca Cola mit der ID 1 eingefügt haben:

1

$Product = $Connection->getTable ( 'Data_Db_Products' )->find ( 1 );

Jetzt haben wir ein Produkt im Speicher mit dem wir weiter arbeiten können. Nun wollen wir zunächst zwei POS einfügen. Dazu dient uns folgender Codeschnipsel:

1
2
3
4
5
6
7
8
9
10
11

$Aldi = new Data_Db_Pos;
$Aldi["name"] = 'Aldi Sued';
$Aldi["description"] = 'Aldi im Sueden und Westen Deutschlands';
$Aldi[ 'date_created' ] = date('Y-m-d');
$Aldi->save();
 
$Lidl = new Data_Db_Pos;
$Lidl["name"] = 'Lidl';
$Lidl["description"] = 'Lidl Stiftung Deutschland';
$Lidl[ 'date_created' ] = date('Y-m-d');
$Lidl->save();

Jetzt greifen wir über das Produkt-Objekt zunächst auf die Variationen des Produkts zu. Hier gehen wir mal davon aus, dass wir wissen, an welcher Stelle die beiden Datensätze stehen und das sie vorhanden sind. Zum Einfügen eines POS zu einer Variation gibt es wieder zwei Möglichkeiten. Die eine über die lose Array-Zuweisung, welche (wie beim letzten Mal erläutert) Performance-Einbußen mit sich bringen kann:

1
2
3
4

$Light = $Product->Data_Db_ProductsVariations[0];
$Light->Data_Db_Pos[] = $Lidl;
$Light->Data_Db_Pos[] = $Aldi;
$Light->save();

Jetzt haben wir die Variante Light zu Lidl und Aldi hinzugefügt. Nehmen wir nun Variante B und fügen Zero zu Lidl hinzu:

1
2
3
4
5

$Zero = $Product->Data_Db_ProductsVariations[1];
$Pv2Pos = new Data_Db_ProductsVariations2pos;
$Pv2Pos [ 'products_variations_id' ] = $Zero [ 'id' ];
$Pv2Pos [ 'pos_id' ] = $Lidl [ 'id' ];
$Pv2Pos->save();

Dies sieht zwar nicht ganz so cool aus, ist aber im Endeffekt performanter. Da die wenigsten Leute sich beim Benutzen der Anwendung für den coolen Source interessieren, sondern eher für die Performance, würde ich Variante B vorschlagen .

Jetzt haben wir genug Daten in der Datenbank, sodass wir sie nun mit einem Query auslesen können:

1
2
3
4

// Auslesen (Alle Produkte-Variationen von Lidl)
$Query = new Doctrine_Query;
$Query->from ( 'Data_Db_ProductsVariations pv, pv.Data_Db_Pos p' );
$Query->where ( 'p.id = ' . (int)$Lidl [ 'id' ] );

Wie man erkennen kann ist die Verknüpfungstabelle transparent. Doctrine weiß selbst durch die Definition welche Verknüpfungen verwendet werden müssen und macht solchen Query daraus:

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

SELECT
    p.id AS
    p__id, p.products_id AS
    p__products_id, p.name AS
    p__name, p.date_created AS
    p__date_created, p2.id AS
    p2__id, p2.name AS
    p2__name, p2.description AS
    p2__description, p2.date_created AS
    p2__date_created FROM
    products_variations p
    LEFT JOIN products_variations2pos p3 ON p.id = p3.products_variations_id
    LEFT JOIN pos p2 ON p2.id = p3.pos_id
    WHERE p2.id = 2

Wenn wir diesen Query nun ausführen und dann durchwandern, sehen wir, dass wir Erfolg hatten. Wir bekommen die beiden hinzugefügten Varianten, die wir zum POS Lidl hinzugefügt haben. Diese sind natürlich unsortiert, aber das kann man nachholen bzw. vorher durch ein orderBy realisieren, wenn man es möchte :

1
2
3
4
5
6
7
8
9
10

$Result = $Query->execute();
 
foreach
(
	$Result as $ProductVariation
)
{
	echo $ProductVariation->Data_Db_Products["name"]." -> " . $ProductVariation["name"];
	echo "<br />";
}

Folgendes Ergebnis können wir betrachten:

Coca Cola -> Light
Coca Cola -> Zero

Über die Objektschnittstellen von Doctrine können wir nun auch vollständig auf die Daten des eigentlichen Produkts zugreifen. Doctrine läd diese Daten dann on-Demand nach.

Nun haben wir 1:1, 1:n und n:m Beziehungen beleuchtet, das gibt uns die Möglichkeit vieles zu realisieren. Im nächsten Beitrag werde ich auf ein weiteres tolles Feature von Doctrine eingehen, die Eventlistener. .
Kommentare sind gern gesehen, Fragen natürlich auch.

1
2
3
4
5
6
7

CREATE TABLE `products_variations` (
  `id` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  `products_id` bigint(20) UNSIGNED NOT NULL,
  `name` varchar(255) collate latin1_general_ci NOT NULL,
  `date_created` datetime NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

Als nächstes legen wir die Datenbank-Klasse für die Tabelle an, hier kommt direkt die erste Besonderheit. Doctrine verwendet für das Einsetzen der Verbindungen zwischen den Klasse eine SetUp-Methode. Diese setzt dann die Verbindungen in folgender Weise:

1
2

        $this->hasOne('Data_Db_Products', array('local' => 'products_id',
                                    'foreign' => 'id'));

Es wird mittels hasOne eine Beziehung gesetzt und zwar wird der lokale Schlüssel products_id mit dem fremden Schlüssel id verknüpft. Dies funktioniert nur bei 1:n Beziehungen in dieser Weise. Für n:m Beziehungen gilt eine andere Schreibweise. Dies wird Thema eines anderen Beitrages sein . Die fertige Datenbankklasse sieht nun folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

class
	Data_Db_ProductsVariations
extends
	Doctrine_Record
{
 
	public function setTableDefinition
	(
	)
	{
		$this->setTableName('products_variations');
 
        $this->hasColumn('id', 'integer', 4, array('notnull' => true,
                                                   'primary' => true,
                                                   'unsigned' > true,
                                                   'autoincrement' => true));
		$this->hasColumn('products_id' , 'integer' , 8 , array ('notnull' => true));
		$this->hasColumn('name' , 'string' , 3000 , array ('notnull' => true));
		$this->hasColumn('date_created' , 'timestamp' , null);
	}
 
	public function setUp()
	{
        $this->hasOne('Data_Db_Products', array('local' => 'products_id',
                                    'foreign' => 'id'));
    }
 
}

Nun hilft uns eine einseitige Verknüpfung in diesem Fall nichts, also setzen wir nun den “n”-Part in der Produkt-Klasse. Diese sieht in einsatzbereitem Zustand so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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);
	}
 
	public function setUp
	(
	)
	{
        $this->hasMany('Data_Db_ProductsVariations', array('local' => 'id',
                                    'foreign' => 'products_id'));
	}
 
}

Jetzt sind wir soweit, dass wir weiter arbeiten können. Wir fügen nun zunächst mal ein Basis-Produkt ein, mit dem wir dann die anderen Beispiele durchgehen. In meinem Fall ist es das Produkt “Coca Cola”:

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

try
{
	$Product = new Data_Db_Products;
	$Product [ 'name' ] = 'Coca Cola';
	$Product [ 'description' ] = 'Erfrischungsgetraenk';
	$Product [ 'date_created' ] = date('Y-m-d');
	$Product->save();
}
catch
(
	Exception $e
)
{
	var_dump($e->getMessage());
}

Ist das Produkt angelegt, machen wir uns daran die Variationsen anzulegen. Hierzu gibt es zwei verschiedene Möglichkeiten. Die Möglichkeit A verwendet die Array-Implementation von Doctrine. Sie ist jedoch nicht wirklich performant, da durch die Schreibweise mit den Array-Klammern zunächst alle bisherigen Einträge gelesen werden müssen, um den korrekten Index berechnen zu können, ich stelle sie jedoch trotzdem vor, der Vollständigkeit halber:

1
2
3
4
5

$Product = $Connection->getTable ( 'Data_Db_Products' )->find ( 1 );$ProductVariations = new Data_Db_ProductsVariations;
$ProductVariations[ 'name' ] = 'Zero';
$ProductVariations[ 'date_created' ] = date('Y-m-d');
$Product->Data_Db_ProductsVariations[] = $ProductVariations;
$Product->save();

Die zweite Variations ist durchaus performanter, führt aber zum selben Ergebnis, verursacht nur weniger Datenbank-Last:

1
2
3
4
5
6

$Product = $Connection->getTable ( 'Data_Db_Products' )->find ( 1 );
$ProductVariations = new Data_Db_ProductsVariations;
$ProductVariations[ 'name' ] = 'Light';
$ProductVariations[ 'products_id' ] = $Product [ 'id' ];
$ProductVariations[ 'date_created' ] = date('Y-m-d');
$ProductVariations->save();

Jetzt haben wir ein Produkt mit zwei Variationsen in die Datenbank gespeichert. Diese wollen wir nun auslesen. Auch dazu gibt es zwei verschiedene Möglichkeiten, die je nach Einsatzzweck beide sinnvoll sind. Will man wirklich explizit nur ein Produkt auslesen, dann verwendet man den Finder, möchte man evtl. viele verschiedene Produkte mit ihren Variationsen auslesen, verwendet man den Query. In diesem Fall ist der Query natürlich nicht so sinnvoll, aber er sei der Vollständigkeit halber vorgestellt. Bei dieser Gelegenheit schauen wir uns dann auch mal einen Query an, den Doctrine generiert. Hierzu müssen wir nur ein echo auf das Query-Objekt machen, denn Doctrine implementiert die __toString()-Methode:

1
2
3
4

$Product = $Connection->getTable ( 'Data_Db_Products' )->find ( 1 );
$Query = new Doctrine_Query;
$Query->from ( 'Data_Db_Products p , p.Data_Db_ProductsVariations' );
$Query->where ( 'p.id = ' . (int)$Product [ 'id' ] );

Doctrine generiert dabei folgenden Query:

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

SELECT
    p.id AS
    p__id, p.name AS
    p__name, p.description AS
    p__description, p.date_created AS
    p__date_created, p2.id AS
    p2__id, p2.products_id AS
    p2__products_id, p2.name AS
    p2__name, p2.date_created AS
    p2__date_created FROM
    product p
    LEFT JOIN products_variations p2 ON p.id = p2.products_id
    WHERE p.id = 1

Wir sehen nun, dass Doctrine einen LeftJoin erstellt. Dies können wir natürlich auch beeinflussen, aber das soll dann Thema eines anderen Beitrags sein. Führen wir diesen Query nun aus

1

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

erhalten wir folgendes Ergebnis. Wobei zu sagen ist, dass ich absichtlich nur ein Array abhole, um Performance zu sparen. Man könnte natürlich auch eine Objekthirarchie abholen.

Array
(
[0] => Array
(
[id] => 1
[name] => Coca Cola
[description] => Erfrischungsgetraenk
[date_created] => 2007-07-30 00:00:00
[Data_Db_ProductsVariations] => Array
(
[0] => Array
(
[id] => 1
[products_id] => 1
[name] => Zero
[date_created] => 2007-07-30 00:00:00
)

[1] => Array
(
[id] => 2
[products_id] => 1
[name] => Light
[date_created] => 2007-07-30 00:00:00
)

)

)

)

Wir erhalten nun ein Array mit dem gesuchten Produkt und mit deinen Variationsen, mehr wollten wir ja nicht . Schauen wir uns nun noch die zweite Variante an (per Finder). Hier haben wir (noch) nicht die Möglichkeit nur ein Array abzuholen. Wir suchen also das Produkt mit der ID 1 und können dann per Pfeiloperator auf die Variationsen zugreifen, die verknüpft sind. Doctrine wird dann im Moment des Zugriffs die betreffenden Daten nachladen (Martin Fowler’s Lazy Loading)

1
2
3
4
5
6
7
8
9

$Product = $Connection->getTable ( 'Data_Db_Products' )->find ( 1 );
foreach
(
	$Product->Data_Db_ProductsVariations as $Variations
)
{
	echo $Variations["name"];
	echo "<br />";
}

Dabei erhalten wir folgendes Ergebnis:

Zero
Light

Es hat also funktioniert . Ich hoffe dies war ein weiterer Einstieg in die Arbeit mit Doctrine . Bei der Arbeit mit Doctrine kann man viele spannende Dinge der Objektorientierung lernen und es findt sich bei fast jedem Überlegen ein neuer “cooler” Weg die Daten zu verarbeiten. Beim nächsten Beitrag werden wir uns mit dem Verknüpfen von n:m Beziehungen beschäftigen. Genauer mit der Verknüpfung von Packungseinheiten zu ProduktVariationsen.

Kommentare sind natürlich willkommen

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.