| JSR-170 als Hilfsmittel zur Migration in Datenbanken |
|
Der JSR 170 versucht Zugriffsmechanismen auf Content Repositories auf API-Ebene zu standardisieren. In einem solchen CMS sind die Informationen hierarchisch in Form eines Baumes angeordnet und über XPath oder SQL-Abfragen zugreifbar. Die sQLshell ist in der Lage, komplette Datenmodelle als XML zu exportieren und auch wieder zu importieren. CMS auf Basis von JSR 170 können das auch - Liegt hier die Basis für Synergien?
SzenarioDie sQLshell kann ein ganzes Datenmodell in XML umwandeln und das Ergebnis (oder auf andere Art und Weise entstandene XML-Daten, die sich an das vorgegebene Schema halten) wieder importieren. Damit kann man auf einfache Art und Weise ganze Datenmodelle zwischen verschiedenen relationalen Datenbanken - sogar unterschiedlicher Hersteller - migrieren. Beim Import in der sQLshell kann man die Daten auch Transformationen unterziehen. Was dort aber nicht geht, ist datensatzübergreifende Transaktionen zu spezifizieren - also zum Beispiel Fälle wie: "Importiere alle Datensätze, außer denen, deren Primärschlüssel in Tabelle XYZ weniger als dreimal importiert wird". Will man solches tun, muß man den entsprechenden Filter schon beim Export benutzen. Eine weitere Möglichkeit wäre eine XSLT-Transformation auf das XML anzuwenden - das dürfte im Szenario einer relationalen Datenbank eher schwierig werden, da XSLT-Transformationen auf dem Document Object Model beruhen, das wiederum notwendig macht, das gesamte XML in den Speicher zu laden. XML-Exports von Produktiv-Instanzen einer Datenbank sind dafuer einfach zu groß. IdeeDie Idee hinter der vorgestellten Methode ist einfach: CMS nach JSR 170 speichern ihre Inhalte persistent. Sie erlauben Zugriff via XPath - einer mächtigen Sprache zur Selektion von Knoten in XML-Bäumen, die auch XSLT zugrunde liegt. Es sollte also möglich sein, den XML-Export eines Datenmodells in ein JSR 170-CMS zu importieren, dann die Änderungen via JSR 170-API durchzuführen und das Ergebnis wieder zu exportieren. Proof-of-ConceptWir legten als Daten den Inhalt einer Testtabelle zugrunde, der im folgenden dargestellt wird:
Man beachte den Namen im Datensatz mit Primärschlüssel (ID) 13. Nachdem Export dieser Daten und dem Import in ein JSR 170-CMS (wir benutzten Apache Jackrabbit ), sieht ein Ausschnitt aus dem Dump des Inhalts des CMS wie folgt aus - man beachte, daß die Daten des Datensatzes wiederzuerkennen sind: unter 1) steht die ID und unter 2) der Name:
Anschließend wurde der Wert der Spalte Name für diesen Datensatz geändert, indem zunächst der entsprechende Knoten selektiert wurde: Node edit = root.getNode( "importxml/sQLshell/EXAMPLE/EXAMPLE.row/NAME/jcr:xmltext/"); Danach wurde der Wert des Attributes geändert: edit.setProperty("jcr:xmlcharacters", "Paul"); Nachdem die Daten aus dem CMS wieder in eine XML-Datei exportiert wurden und diese Datei durch die sQLshell wiederum in eine Datenbank importiert wurde, sieht man die Änderungen am Datensatz mit Primärschlüssel (ID) 13 deutlich:
|




