[TYPO3-german] gesucht: Extension, um Datenbankobjekte als XML zu exportieren und woanders als XML zu importieren

_doc _doc at freenet.de
Sat Mar 2 09:42:17 CET 2019


Liebe Mitleser,

der Viewhelper f:debug wandelt ein Datenbank Object in eine HTML-Ausgabe 
um.  Ich suche eine Extension, die ähnliches macht - nur ein bisschen 
allgemeiner. Ich möchte TYPO3 zur Datenerfassung nutzen, und die 
erfassten daten später exportieren können. Es geht mir also darum, dass 
ich unter TYPO3 ein komplexes Datenbankobjekt von einer TYPO3-Aufsetzung 
exportieren und in eine andere TYPO3-Aufsetzung importieren kann.

ich suche also eine Extension mit folgenden zwei Eigenschaften.
Sie soll ein Datenbank-Objekt, das ich per Repository von Extbase 
erhalte, in einen XML-String umwandeln können.
Sie soll ein XML-String inklusive der Resourcen in ein Datenbank-Object 
umwandeln und unter TYPO3 in der Datenbank zurückbauen/persistieren können.

Mir fehlt leider die Zeit, eine solche Klasse mal eben nach Feierabend 
zu programmieren. Andererseits ist das Problem so allgemein, dass 
eigentlich eine Lösung existieren sollte. Mit Symfonys ORM-Builder kenne 
ich mich zuwenig aus, um zu prüfen, ob ich über den Umweg von 
stdClass-Objekten gehen könnte. Ein Umweg über PHP-Arrays oder über 
JSON-Strings wäre mir auf recht.

Weiß jemand, ob ein solches Konstrukt schon einmal gebaut wurde oder 
existiert. Eine Herausforderung eines solchen Konstrukt ist, dass man 
mit absoulten Keys oder mit Hashs plus Datenabgleich bei Hash-Gleicheit 
arbeiten muss, wenn man die N:1-Relation korrekt abbilden und 
Sicherstellen will, dass nach der Konversion der Konversion eine 
identische Kopie vorliegt.

Das Framwork darf ausschließen, das es zirkuläre Datenbeziehungen gibt.

Die Extension sollte also im Idealfall folgenden bijektiven 
Umwandlungsregeln erfüllen.
0. Im XML sind werden die UID's durch Hash-Werte für den Datensatz ersetzt.
1. Konvertierung Field(Fieldname)
DB(Fieldname=>Data)  <-> XML(<fieldname>data</fieldname>)
1.b. Konvertierung Field(ResourcenID)
DB(Fieldname=>ResourcenID)  <-> XML(<fieldname 
filepath="ResourcenID">base64(ResourcenID)</fieldname>)
2. Konvertierung Field(DatensatzUid) der Tabelle TabellenName (setzen 
von Hash-Attribut)
DB(Fieldname=>DatensatzUid; tabellenName)  <-> XML(<tabellenName 
fieldName="{hash von inkludierten Datensatz}">{ enthält alle Felder 
inklusive der referenzierten Tabellen}</tabellenName>)
3. Konvertierung Datensatz aus Tabelle(TabellenName, Uid)
DB(tabellenName=>Fields) <-> XML(<tabellenName>{Aufruf Field(fieldname) 
für alle Fields}</tabellenName>)
4. Konvertierung Relation 1:1 Relation(TabellenName); TabelleForeign,  
RefForeign implizite Information
DB(FieldRelation=>RefUid; TabelleForeign, RefForeign) <-> 
XML(<fieldRelation count="1" 
child="RefForeign">{Tabelle(TabelleForeign,RefUid)}</fieldRelation>)
4.b. Konvertierung Relation 1:n Relation(TabellenName); TabelleForeign, 
RefForeign implizite Information
DB(FieldRelation=>RefCount; TabelleForeign; RefForeign) <-> 
XML(<fieldRelaton count="RefCount" 
child="RefForeign">{{Tabelle(TabelleForeign,Uid)} für alle Uids, die im  
ForeignField den ID des aktuellen datensatze enthalten}</fieldRelation>)
5. Konvertierung von N:1-Relationen (TabellenName->RefField) implizite 
Infos zu TabelleForeign, UidForeignName und UidForeignValue
DB(RefField=>UidForeignValue; TabelleForeign; UidForeign) <-> 
XML(<fieldReferenz parent="{Hash von von inkludiertem Datensatz zu 
UidForeignValue}">{Tabelle(TabelleForeign,UidForeignValue)}</fieldReferenz>)
6. Konvertierung Relation M:N Relation
Eine M:N-Relation kann als Relation von M:1 und 1:N betrachtet werden. 
Die Konvertierungen sind oben schon definiert worden.

Vermutlich muss der Zusammenbau mehrschrittig erfolgen, da über 
Hash-Werte sichergestellt werden muss, dass nach dem Rückbau eines 
Exports sicher genausoviel Datensätze wie vorher vorhanden sind. Im 
Idealfall prüft das System sogar, ob bestimmte Teilobjekte in der 
importierenden Datenbank schon vorhanden sind, um das doppelte Anlegen 
von Teilstrukturen tzu vermeiden. Wenn dass nach dem Import ein 
nachträglicher Clearing_prozess übernimmt, soll mir das auch recht sein.

Über Hinweise werde ich mich freuen.

Dieter


-- 

---

Dr. Dieter Porth
Grünenstraße 23
D-28199 Bremen
Germany

+(049) 421 / 51 48 35 48
+(049) 160 / 99 18 06 88 (abends/ after 18:00)



More information about the TYPO3-german mailing list