Mein letzter Eintrag liegt schon wieder eine ganze Weile zurück. Ich habe mir vorgenommen, dieses Jahr ein wenig regelmäßiger zu schreiben. Vor allem auch über nicht-computer Themen ;-)

Schon seit einiger Zeit wollte ich mir die objekt-orientierte Datenbank Db4o für Java ansehen, hat doch diese Datenbank vielerorts von sich reden gemacht. Angespornt durch die Ankündigung, dass die nächste anstehende Version 6.0 Verbesserungen bezüglich des Speicherverbrauchs und der Performance mitbringen soll, habe ich mir also nun endlich einmal Db4o näher angesehen.

Was ist nun der Unterschied zu einer traditionellen relationalen Datenbank, insbesondere in Verbindung mit Hibernate? Nun, der wesentliche Unterschied ist der, dass man sich keine Gedanken darüber machen muss, auf welche Art und Weise man sein Datenmodell in die Datenbank persistieren kann. Man schreibt also einfach sein Datenmodell, erzeugt eine Instanz und speichert diese in der Datenbank ab:

ObjectContainer db = ...
db.set(myObject);

Das war's. Db4o wandert automatisch alle Kind-Referenzen ab und speichert diese ebenfalls. Angenommen man hätte folgende zwei Klassen:

public class Parent {
    private String name;
    private List childs = new LinkedList();     
    public Parent(String name) { this.name = name }
    public void addChild(Child child) {
        childs.add(child);
    }
}

public class Child {
    private String name;
    ...
}

und man würde folgende Instanzen erzeugen:

Parent p = new Parent("parent");
p.addChild(new Child("child 1"));
p.addChild(new Child("child 2"));

so würde Db4o automatisch alle Childs mitabspeichern, wenn man Parent p mit db.set() speichern würde.

Doch wie schaut es mit der Abfrage aus? Db4o unterstützt verschiedene Anfrage-Sprachen (QBE, Native Queries, S.O.D.A), wobei SODA quasi die Low-Level API darstellt. Obwohl Db4o selber die Verwendung von Native Queries empfiehlt, sagt mir die Low-Level API SODA eher zu. Ein paar Beispiele:

Finde ein Parent-Objekt mit dem Namen "parent" :

query.constrain(Parent.class).descend("name").constrain("parent").equal();

Finde ein Parent-Objekt, dessen Child den Namen "child 1" hat:

query.constrain(Parent.class).descend("childs")
    .descend("name").constrain("child 1").equal();

Selbstverständlich sind auch komplexere Anfragen möglich. Sofern es meine Zeit zulässt, werde ich in den folgenden Tagen von meiner praktischen Erfahrung mit Db4o berichten. Der erste Eindruck ist auf jeden Fall schon mal ganz angenehm =)

Eigentlich sollte man meinen, dass die Entwicklung und Pflege einer Weblog-Engine kein großer Aufwand sei. Doch die Tücke steckt wie so oft im Detail. Denn ich entdecke immer wieder Dinge, die ich gerne verbessern würde. Daher habe ich heute an der Behandlung der Tags gearbeitet. Wählt man jetzt auf der rechten Seite einen Tag aus, so wird die typische Auflistung inklusive Pagination beibehalten, nur dass der Inhalt auf alle Einträge mit dem gewählten Tag reduziert wird. Die Kategorien habe ich ganz herausgenommen, da sie im Grunde nur eine Redundanz zu den flexibleren Tags waren.

Desweiteren habe ich ein wenig mit den Fragment Cache Techniken von Rails gespielt. Somit konnte ich die Zeit für das Rendering der Home-Seite erheblich drücken und damit die Performance um den Faktor 3 verbessern. Ich finde, das ist ein ganz passables Ergebnis ;-)

Ich hoffe nur, ich habe alle Stellen gefunden, an denen der Cache geflushed werden muss ... =)

Soeben habe ich woeye.net auf das neue System umgezogen. Hoffentlich funktioniert soweit alles ...

Gerade habe ich diese lustige Seite entdeckt: www.linerider.com. Und was damit möglich ist, sieht man in diesem Filmchen auf YouTube =)