Download (5Mb) - oops/ - Oldenburger Online-Publikations-Server

98 Umsetzung des Prototyps
eines Platzhalter-Textes ausgeführt – z.B. in dem “Satz” $Pass-is_HERE/ wird den Platzhalter
“HERE” durch den entsprechenden Passwort ersetzt.
Der nächste Schritt in der Bereitstellung der Datenbank-Umgebung ist das Laden und die letzte
Vorbereitung der Modelle, die in der Datenbank als Relationen gespeichert werden.
Ladevorgang und Vorbereitung des Datenmodells
In diesem Schritt werden die von dem Komanndozeile-basierten Programm gelieferten und ggf.
noch manuell verarbeiteten Ruby-Klassen geladen. Mittels Ruby werden erstmal die einzelnen Dateien
rekursiv aus dem Dateisystem geladen (mithilfe des require Befehls). Somit sind alle in der
Abbildung 7.1 dargestellten Klassen dem Backend-System bekannt und die letzten Vorbereitungen
können anfangen.
Nachdem alle Modelle (in der DataMapper Terminologie auch als “Ressourcen” bekannt) geladen
sind, müssen die “abgeschlossen” bzw. überprüft werden. Der Befehl DataMapper.finalize!
ist dafür zuständig. Dieser Zwischenschritt ist benötigt, um diejenige deklarierten Modelle nach Fehler
wie z.B. eine nicht unterstützte Kardinalität (beispielsweise “0..3” anstatt “0..n”) zu untersuchen
sowie die mit den Assoziationen verbundenen Getters und Setters zu initialisieren.
An dieser Stelle ist der Umgang mit dem Datenmodell für die Formulierung von Befehlen wie z.B.
die Erstellung von Instanzen bereit. Die Ausführung der Befehle setzt voraus, dass die Migration (d.h.
die entsprechende Darstellung der Modelle als Relationen in der Datenbank) schon abgeschlossen
bzw. durchgeführt ist. Dieser Schritt wird im kommenden Paragraph erläutert.
Initielle Migration und Befüllung der Datenbank
Der “Seeding” Vorgang muss zuerst über eine Datenbankschema verfügen – zur Zeit wurde nur die
Datenbank und deren Rollenverwaltung durchgeführt worden. Für die Erstellung einer Schema (meist
im engl. als ein “migration” bekannt) müssen weitere DDL Befehle übergeben werden, wodurch die
einzelnen Relationen erstellt werden. Dieser Schritt erfolgt fast automatisch dank dem genannten
“DataMapper” ORM, mittels der DataMapper.automigrate! Befehl.
Die Auswirkung dieses Befehls ist es, dass diejenige Klassen, die mit Eigenschaften (Attributen)
und Assoziationen (Beziehungen) versehen und als DataMapper “Ressourcen” markiert sind, sich in
der Datenbank wiederfinden werden. Das ORM kapselt dann dieser Prozess (die Ausführung von
DDL Befehle wie z.B. CREATE TABLE) ein, abstrahierend von der händischen Übergabe von DDL-
Befehlen und die eventuell damit verbundene Fehlerbehandlung.
Das Konzept einer “Migration” berührt am meisten die einzelnen Schritte, die erfolgen müssen, um
einen gewissen Zustand der Datenbank bzw. des Datenbasis zu erreichen. Beispielsweise lässt sich
die Erstellung einer einzigen Relation auch als ein “Migrationsschritt” ansehen. Vorteilhaft bei diesem
Konzept ist die Möglichkeit, eine ausgeführte Migration zurücksetzen zu können – damit wird den
umgekehrten Weg einer Migration beschrieben. In der entwickelten Softwarelösung wird die ganze
Erstellung der zum Datenmodell gehörenden Relationen als eine einzige Migration gesehen, die durch
eine erneute Initialisierung behoben werden kann.
Nachdem die Relationen erstellt sind, lassen sich diejenige ursprünglichen Datenbestände dadrin
speichern – wie herausgestellt, ist dieser Prozess durch den Bezeichner “seeding” beschrieben. In
diesem Fall werden die ursprünglichen Elementen des Datenmodells in der Datenbank mittels DML