Spätestens seit den 90er Jahren gehört objektorientiertes Programmieren zum flotten Alltag. Geht es um dauerhafte Speicherung, steigen Entwickler aber immer noch auf ein rostiges Dreirad um. Damit ist Schluss: Die Objektdatenbank Db4o konserviert mit wenigen Zeilen auch komplexe Objektstrukturen.

Blubberblasen

SODA bezeichnet in diesem Fall kein Getränk, sondern die dritte von Db4o unterstützte Abfragesprache. Das Akronym steht für Simple Object Database Access. Im Vergleich mit den Native Queries bedeuten sie etwas mehr Schreibarbeit. Dafür erlaubt sie einen feingranularen Zugriff auf die Abfrage, die Db4o auch noch relativ fix ausführt. Die Db4o-Entwickler bezeichnen SODA daher auch als ihr Low Level Query API.

Um per SODA an alle Kunden heranzukommen, die in »Hinkburg« wohnen, ist zunächst ein neues Query-Objekt nötig:

Query query = db.query();

Es repräsentiert eine Datenbankabfrage, die in diesem Zustand noch alle Objekte aus der Datenbank zurückliefern würde. Folglich muss die Ergebnismenge etwas schrumpfen beziehungsweise sich auf die gewünschten Objekte beschränken. Im Beispiel interessieren nur alle Kunde-Objekte:

query.constrain(Kunde.class);

Wenn die Suche anschließend mit der Anweisung

ObjectSet ergebnisse=query.execute();

beginnt, liefert Db4o alle gespeicherten Personen-Objekte aus der Adressdatenbank zurück. Um nur alle Kunden aus »Hinkburg« zu erhalten, ist eine weitere Einschränkung der Adresse fällig:

query.descend("adresse").constrain("Hinkburg");

Dieser Befehl hangelt sich zunächst zu dem Attribut mit dem Namen »adresse« durch und gibt ihm die Einschränkung »Hinkburg«. Abbildung 1 zeigt einen solchen Graphen, in dem jeder Knoten eine Einschränkung erhält. Die Funktion »descent()« durchläuft dann den Graphen. Auch komplexe Abfragen sind mit dieser etwas gewöhnungsbedürftigen Notation möglich. Listing 4 liefert beispielsweise den Kunden aus »Neustadt« mit der Kundennummer »56321«.

Abbildung 1: Graph einer SODA-Abfrage, bei der die Knoten Suchbedingungen festlegen.

01 Query query=db.query();
02 query.constrain(Kunde.class);
03 Constraint constr=query.descend("adresse").constrain("Neustadt");
04 query.descend("kundennummer").constrain(new Integer(56321)).and(constr);
05 ObjectSet ergebnisse=query.execute();

Neben »and()« bietet SODA alle üblichen und noch viele weitere nützliche Operatoren. Eine vollständige Referenz steht unter [4] bereit. Da umfangreiche Abfragen in recht komplexe Gebilde ausarten können, wird der Anwender in der Praxis hauptsächlich auf Query by Example oder Native Queries zurückgreifen. Die Nutzung des SODA-API bietet sich vor allem dann an, wenn Abfragen dynamisch zu erzeugen sind. Dabei ist jedoch stets zu beachten, dass es keinen verbindlichen Standard gibt, im Gegenteil: Als offenes Sourceforge-Projekt sieht sich SODA noch munteren Änderungen unterworfen [4].

Die bei einer Suchanfrage zurückgelieferten Objekte sind grundsätzlich vollständig instanziiert. Wenn ein Kunde eine Referenz auf seine Bestellung enthält, würde Db4o nicht nur die gesuchte Person, sondern auch gleich noch das von ihr referenzierte Bestell-Objekt zurückliefern. Diese Automatik hat jedoch ihre Grenzen. Beispielsweise dann, wenn sie Objekte in der Datenbank aktualisieren oder aus ihr löschen muss. Das Update eines einfachen Objekts in der Datenbank übernimmt »set()«:

herrbert.setName("Herr Appeldorn");
db.set(herrbert);

Db4o erkennt selbstständig, dass das Objekt bereits in der Datenbank liegt und also nur noch aktualisiert werden muss. Um es komplett aus der Datenbank zu werfen, spürt man es zunächst auf und schickt es dann per »delete()«-Befehl ins Nirwana:

ObjectSet ergebnisse=db.get(new Kunde("Herr Bert",null, 0));
Kunde herrbert=(Kunde)ergebnisse.next();
db.delete(herrbert);

Wenn nun ein Kunde mit einer Bestellung verbunden ist, stellt sich für Db4o die Frage, ob es genau jene Bestellung ebenfalls aktualisieren beziehungsweise löschen muss. In diesem einfachen Beispiel lässt sich die Frage noch recht schnell klären. In der Praxis herrschen gewöhnlich jedoch weitaus komplexere Beziehungen. Im Fall einer Aktualisierung müsste Db4o unter Umständen zunächst eine riesige Menge von Objekten instanziieren, denn schließlich hängt an dem Objekt ein Objekt, an dem ein Objekt hängt.

Objekt-Hierarchien

Wie tief soll Db4o also in die Objekt-Hierarchie hinabsteigen? Da die Datenbank diese Frage nicht mehr selbst lösen kann, überlässt sie die Entscheidung dem Programmierer. Die Anzahl der Hierarchie-Ebenen, die Db4o berücksichtigt, heißt dabei Update Depth. Der Ausdruck

Db4o.configure().objectClass("Kunde").cascadeOnUpdate(true);

weist Db4o an, bei einem »Kunde«-Objekt grundsätzlich allen Referenzen bis zum bitteren Ende zu folgen, also so tief wie möglich in die Objekt-Hierarchie hinabzusteigen. Die passende Konfigurationsanweisung für den Löschvorgang lautet analog:

Db4o.configure().objectClass("Kunde").cascadeOnDelete(true);

Damit verschwindet auch die an dem zu löschenden Personeneintrag hängende Bestellung aus der Datenbank. Um ihre Wirkung zu entfalten, muss der Programmierer die Konfigurationsbefehle übrigens immer vor dem Öffnen eines Containers absetzen.

Das Problem mit den Hierarchien taucht noch an einer anderen Stelle auf. Dies lässt sich am einfachsten mit einer verketteten Liste wie der aus Listing 5 demonstrieren. Eine Bestellung verweist einfach über »next« auf die nächste Bestellung. Der Kunde braucht dann nur noch eine Referenz auf das erste Element in der Bestellkette.

01 class Bestellung{
02     private String produkt;
03     private Bestellung next;
04     public Bestellung getNext() {
05             return next;
06     }
07     ...
08 }
09 
10 class Kunde {
11     ...
12     private Bestellung erstebestellung;
13     public Bestellung getErstebestellung() {
14             return erstebestellung;
15     }
16     ...
17 }

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Spätestens seit den 90er Jahren gehört objektorientiertes Programmieren zum flotten Alltag. Geht es um dauerhafte Speicherung, steigen Entwickler aber immer noch auf ein rostiges Dreirad um. Damit ist Schluss: Die Objektdatenbank Db4o konserviert mit wenigen Zeilen auch komplexe Objektstrukturen.