henso.com
Home
Archive
Search

rss feed for this page

DELI
HLM

LNGR
EURN
OON
CHLM
POOL
ELPH
RIST
SOFA
SENS
P3K
FM4
SCRP
MAL
RNS
GDNY
ELEG
OSNS
SLSH

Mozilla, baby!

antville.org
 Monday, 6. August 2001 

Full throttle.

Drop resistance and communication skills.

Wear tight chinese Gung t-shirt.

Das Ergebnis der letzten Woche: Helma hat endlich ein Objekt- und Cache-Management, das der Hopschen Funktionsweise entspricht. Prinzipiell wird auf persistente (in einer Datenbank gespeicherte) Objekte über einen Schlüssel aka Key zugegriffen. Der Key enthält die Datenquelle und ID des Objektes. Wenn also eine Hop-Application auf ein persistentes Objekt zugreift, sendet sie dessen Key an den NodeManager. Der schaut zunächst, ob für diesen Key bereits ein Objekt in seinem Cache existiert, andernfalls holt er sich das Objekt aus der Datenbank.

So weit so gut. Nun ist aber eine der grössten Stärken des Hop, dass er imstande ist, mit symbolische Referenzen zu arbeiten, die erst zur Laufzeit aufgelöst werden. Ein einfaches Beispiel ist die URL my.orf.at/hns. Das "hns" ist in diesem Fall nicht der primäre Schlüssel meines Records in der ORF ON User-Datenbank. Der ist vielleicht "423412", was ich aber nicht weiss, weil ich ihn nie zu Gesicht bekommen habe. Stattdessen werden die Objekte über eine ihrer Eigenschaften, in diesem Fall den User-Namen, in my.orf.at/ gemountet. Jede Anfrage in der Form "my.orf.at/<xxx>/yyy wird also anhand des Type-Mappings in eine Datenbankabfrage umgesetzt, ob ein Objekt existiert dessen User-Name gleich "<xxx>" ist. Ein anderes Beispiel für symbolische Referenzen sind virtuelle und Groupby-Nodes. Virtuelle Nodes sind frei definierbare Behälter für Objekte, Groupby-Nodes sind Behälter, die Objekte nach einer ihrer Eigenschaften gruppieren. Beide Arten von Objekten existieren nicht in der Datenbank, sondern werden vom Hop bei Bedarf on-the-fly erzeugt. So ist zum Beispiel das "/log/2001.08.06" in der permanenten URL dieses Eintrags ein Groupby-Node, der alle Einträge auf henso.com enthält, die am 6. August 2001 angelegt wurden. Das Objekt selbst existiert nicht in der Datenbank, aber Hop-intern und -extern steht es genau dann zur Verfügung, sobald in der Datenbank mindestens ein Weblog-Eintrag mit diesem Entstehungsdatum existiert.

Mit dieser Art von Objekt-Referenzen, die natürlich auch gecacht werden müssen, hatte der Hop bisher Probleme. Es war zwar kein Problem, die Key-Klasse so zu vergewaltigen, dass sie imstande war, für solcherart symbolisch referenzierte Objekte eindeutige Schlüssel zu liefern. Falls das Objekt aber nicht im Cache gefunden wurde, war es unschön, das angeforderte Objekt anhand des Schlüssels von der Datenbank zu holen oder neu zu erzeugen, weil die im Schlüssel enthaltene Information - (Pseudo-)Datenquelle und (Pseudo-)Objekt-ID - eben keine Anleitung dazu mehr liefern konnte.

Die Lösung des Problems: Key ist jetzt ein Interface, das von zwei Klassen implementiert wird: Dem oben beschriebenen DbKey, der wie gehabt Datenquelle und Objekt-ID beschreibt, und einer neuen Klasse namens SyntheticKey, die stattdessen einen Key zu einem anderen Objekt und eine Beschreibung enthält, wie das eine Objekt vom anderen erhalten werden kann. Das schöne daran ist, dass diese Ableitungsregel der gleiche einfache symbolische Name ist, der z.b. in URLs verwendet werden kann, weil der Hop mit seinem Type Mapping ja weiss, wie er aus dem symbolischen Namen eine konkrete DB-Query oder ein virtual- oder groupby-Objekt erzeugen kann.

In diesem Licht wiederhole ich mein vorgestriges Vorher - nachher-Posting. (Update: die vorher-Ansicht "funktioniert" nicht mehr, weil ich auf antville.org gestern abend den neuen Snapshot aufgespielt habe. Was gezeigt werden sollte war, dass die alten Keys grauslig verrenkt ausschauten ;-)

In der nachher-Ansicht sieht man zwei Arten von Keys: solche mit und ohne "Pfad" am Ende.

weblog[1]
[0]
[1]
[1]/hns
[1]/jo6pack
skin[2]
skin[3]
weblog[1]/skinmanager
weblog[1]/skinmanager/story
weblog[1]/skinmanager/story/preview

Bei den Keys ohne Pfad handelt es sich um Instanzen von DbKey. "weblog[1]" ist beispielsweise das Objekt vom Typ weblog mit der Objekt-ID 1. Wenn vorne kein Typname dransteht bedeutet das, dass das Objekt nicht in einer relationalen Datenbank, sondern in der internen Objektdatenbank gespeichert ist. "[0]" ist z.b. das Root-Objekt der Application, "[1]" das User-Root-Objekt. Die Objekte mit Pfad hintendran sind hingegen Instanzen von SyntheticKey. Man sieht hier auch, wie sich synthetische Keys nicht nur auf DbKeys, sondern wiederum auf andere synthetische Keys beziehen und so "Key-Ketten" bilden können. Zum Bespiel ist "weblog[1]/skinmanager" ein virtuelles Objekt, das an "weblog[1]" gemountet ist und die Skin-Objekte für dieses Weblog enthält. "weblog[1]/skinmanager/story" ist ein Groupby-Objekt, das alle Skins dieses Weblogs enthält, die zum Prototyp "story" gehören. "weblog[1]/skinmanager/story/preview" schliesslich ist persistentes Skin-Objekt, das beschreibt, wie die Voransicht von Stories auf diesem Weblog ausschauen soll. Dieses Skin-Objekt ist auch noch mit seinem primären Key "skin[3]" im Cache des Node-Managers enthalten.

PS: obige Anordnung und Struktur der Skins in Antville ist im Type-Mapping des weblog-Prototyps durch folgenden Zeilen definiert:

skinmanager=[virtual]skin.NAME
skinmanager.subnodeRelation=<skin.WEBLOG_ID
skinmanager.areSubnodes=true
skinmanager.groupby=PROTO

Ja, das Format der type.properties-Files ist nicht super-intuitiv. Wir denken schon über ein neues Format nach, das etwas weniger konzis und etwas mehr expressiv ist ;-)

Themenwechsel: Der einzige Grund, warum viele Leute keinen grünen Tee mögen (oder komisch aromatisierten grünen Tee trinken) ist dass sie ihn zu lang ziehen lassen. Eine Minute reicht völlig. Von Tricks wie kurz aufbrühen, wegschütten und wieder aufgiessen halt ich nichts.

Dan Clowes und Terry Zwigoff im Salon.com-Gespräch. Vielleicht schaue ich mir Ghost World doch an.

Interview mit Richard Stallman.


 earl , 6. August 2001 gegen 11:50 

wow! grandios, grandios. und nachdem sich der inhalt noch zu wandeln scheint, lese ich das in einer stunde (oder so) gleich nochmal ;)

 wikinger , 6. August 2001 gegen 16:13 

Hi Hannes.
Danke daß Du meine Adresse geändert hast. Ich dachte, Du hättest das schon vergessen - Du hast etwas benebelt gewirkt, als du das versprochen hattest. Der Alkohol geht ja auch an Dir nicht spurlos vorbei.
Schöne Grüße Katja

Log in to add your comment!

Not logged in. Click here to log in.

 comments