Bei Doctrine 2 handelt es sich um einen kompletten Redesign des Codes und der Infrastruktur. 90% des Codes wurden neu geschrieben und in neue Konzepte gepresst. Das neue Doctrine 2 ist in Pakete aufgeteilt, die aber höchst wahrscheinlich bei den meisten im Paket verwendet werden:

• Doctrine Common (Generic components, high re usability)
• Doctrine DBAL (The database abstraction layer, includes: Common)
• Doctrine ORM (The ORM tools, includes: Common + DBAL)

Die Pakete können separat runtergeladen werden, und werden im Moment (noch) gleichzeitig released und maintained, dies kann sich aber wohl in Zukunft ändern.

Einige Tools von Doctrine 1 (z.B. das CLI oder die Migrations) befinden sich noch in der Entwicklung und werden ggf. später im Extension Repository landen und nicht mehr im Core enthalten sein, das ist aber aktuell noch nicht geklärt.

Generell sei zu sagen, dass dieser Release nicht für die Produktion gedacht ist, sondern für die Community als ersten Test, um ein wenig mit dem neuen Core warm zu werden. Ein Quickstart Tutorial wurde hier veröffentlicht. Der Download ist hier zu finden, Bugs können – wie immer – im Trac gemeldet werden.

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.

Jetzt hatte ich wieder den Fall, dass ich einen simplen Select hatte, in dem ich entscheiden mußte, ob ich das Datum der Einstellung oder das Datum der Aktualisierung des Datensatzes zum Sortieren benutze. Das verlangt einen Vergleich im Query, den man in SQL folgendermaßen abfangen kann:

1

SELECT i.*, IF(i.date_created > i.date_updated, i.date_created , date_updated) AS date_compare FROM item AS i ORDER BY date_compare

Das in einen Doctrine-Query gepackt sieht so aus:

1
2
3
4
5

$Query = new Doctrine_Query;
$Query->select ( 'i.*, IF(i.date_created > i.date_updated, i.date_created , date_updated) as date_compare' );
$Query->from ( 'Db_Item i' );
$Query->orderBy ( 'date_compare' );
$Result = $Query->execute(array(),Doctrine::FETCH_ARRAY);

Das so ausgeführt wirft eine Exception, weil Doctrine mit dem Funktionsaufruf IF nicht zurecht kommt, da sie nicht zum Standard gehört. Jetzt habe ich bisher immer einen Workarround gefunden, doch diesmal wollte ich mich damit nicht abgeben. Nach einiger Recherche kam ich auf ein Blog, welches sich um sfDoctrine dreht (das Symfony Plugin basierend auf Doctrine). Hier ist genau dieses Problem beschrieben und es wird eine Option beschrieben, mit der man beeinflussen kann, wie sehr der Doctrine Parser auf Kompatibilität zu anderen DBMS achtet.

Folgendes Beispiel funktioniert wie gewollt:

1
2
3
4
5
6
7

Doctrine_Manager::getInstance()
->setAttribute(Doctrine::ATTR_PORTABILITY, Doctrine::PORTABILITY_ALL ^ Doctrine::PORTABILITY_EXPR); 
$Query = new Doctrine_Query;
$Query->select ( 'i.*, IF(i.date_created > i.date_updated, i.date_created , date_updated) as date_compare' );
$Query->from ( 'Db_Item i' );
$Query->orderBy ( 'date_compare' );
$Result = $Query->execute(array(),Doctrine::FETCH_ARRAY);

Man kann also die Portability über das Entfernen des Flags PORTABILITY_EXPR beeinflussen und damit verlangen, dass der Doctrine-Query-Parser auf solche Dinge nicht mehr achtet. Da lohnt sich vielleicht sogar der Blick in den Source bzw. die Api-Doku, vielleicht finden sich ja noch mehr solche Einstellungen .

Ich hoffe anderen damit helfen zu können, wie mir der Blog-Eintrag Symforc geholfen hat .

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 ..

Nachdem wir uns in den letzten Beiträgen die generelle Funktionsweise von Doctrine angesehen haben, wollen wir uns nun die weiterführenden Features ansehen. Heute beginnen wir mit dem NestedSet. Mit diesem ist es möglich eine Baumstruktur datenbankseitig abzubilden, zu durchwandern und diese zu ändern. Doctrine bringt dieses Feature nativ mit. Hierbei sei gesagt, dass diese Komponente sich noch ständigen Änderungen unterzieht. Für mein Beispiel verwende ich die Revision 2630, die ich aus dem SVN ausgecheckt habe.

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 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

Nachdem wir uns im letzten Beitrag nochmal mit dem Beziehungen der Datenbanktabellen und Klassen beschäftigt haben, wollen uns heute einem weiteren Kapitel widmen, den Event-Listenern.

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 .

1
2

$Collection = $Connection->getTable('Data_Db_User')->find(1);
$Collection->delete();

oder

1
2
3
4
5

$Query = new Doctrine_Query;
$Query->from('Data_Db_User u');
$Query->where ('u.id = 1');
$Result = $Query->execute();
$Result->delete();

Das war meiner Meinung nach ziemlich umständlich, doch ein Blick in die Doku der jetzigen (neueren) Revision lies mich erfahren, dass man nun auch einfach über einen Query löschen kann. Dies kommt nun der “normalen” Art und Weise der Löschung sehr nahe. Vielleicht war es bisher auch möglich, aber leider nicht dokumentiert:

1
2
3
4
5

$Query = new Doctrine_Query;
$Query->delete();
$Query->from ('Data_Db_User u');
$Query->where('u.id = 1');
$Query->execute();

Das ist meiner Meinung nach ein eindeutiger Fortschritt und erspart einem die Umwege über die Doctrine_Collection, welche dann wieder Performance frißt. Also ein Schritt in die richtige Richtung .

Nachdem im letzten Beitrag das Thema 1:n Beziehungen beleuchtet haben, wenden wir uns nun der letzten Beziehungsart zu, die man mit einer Datenbankrelation abbilden kann, nämlich der n:m Beziehung.
Als Basis dazu nehmen wir die Klassen und Datenbanktabellen, die wir in den letzten beiden Artikeln erstellt haben und tauchen nun wieder in die Anwendung ein. Wir möchten nun festhalten, dass die verschiedenen Variationen (Light, Zero) eines Produkts (Coca Cola) in verschiedenen Handelsunternehmen (POS = Point of Sale) verkauft werden.
Dies lässt sich ja auf Datenbankebene mit einer Verknüpfungstabelle darstellen, die die beiden Fremdschlüssel von den Jeweiligen Entitäten enthält und diese so mit einander verknüpft. Auf diese Weise können beliebige Kombinationen in beliebiger Anzahl dargestellt werden. Als Schutz vor Doppeleinträgen machen wir aus dem Datensatz in der Verknüpfungstabelle einen kombinierten Primärschlüssel, sodass hier Datenbankseitig bereits vor Doppeleinträgen geschützt wird. Doctrine reagiert beim Versuch einen Doppeleintrag anzulegen mit einer Exception, die von PDO geworfen wird.

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.

Nach dem wir im letzten Beitrag die Grundlagen zu Doctrine gelernt haben, wollen wir heute ein wenig weiter in die Tiefe gehen.
Wir nehmen wieder unser Beispiel und nehmen an wir haben ein Produkt z.B. Coca Cola. Hierzu gibt es viele Varianten wie z.B. Zero, Light, Cherry. Diese wollen wir speichern und dabei das Original- bzw. Basisprodukt nur einmal speichern. Dies ist eine 1:n Beziehung, die wir in Doctrine abbilden möchten.
Der Grundaufbau der Includes etc. ist genau der selbe, wie wir ihn beim letzten Mal verwendet haben, daher will ich diesen nicht mehr erläutern.Beginnen wir nun direkt und erzeugen zunächst die Datenbank-Tabelle, in der wir die Variationsen speichern werden. Alles natürlich rudimentär. Hierzu dient folgender SQL-Befehl:

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