Alexander Stelter – foo, bar, baz

Wie mein Kollege Fabian Freiburg im das-ist-drin.de Blog berichtet, haben die Entwickler von Doctrine ihr Versprechen wahr gemacht und in der Nacht vom 31. August 2007 den Release Candidate Nummer 1 des gleichnamigen Datenbank ORM Tools für PHP veröffentlicht.

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

written by Alexander \\ tags: das-ist-drin.de, Doctrine, enterprise, mysql, orm, PHP, release candidate 1

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.

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: Continue reading »

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

Nach meinem bisherigen Wissen, konnte man nur Datensätze über Doctrine löschen, wenn man sie zuvor über eine Doctrine-Collection selektiert hat, dies konnte dann mittels finder oder Query passieren:

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 .

written by Alexander \\ tags: delete, Doctrine, doctrine_query, löschen, orm, PHP

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.

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. Continue reading »

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

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.

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. Continue reading »

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