PoC automatische Modell-Generierung

[nitram509]

Hi,

ich habe in einem privaten Projekt die XMLs geparst und nach Postgis geschrieben.
Eure yaml specs finde ich eine gute Idee und dachte man könnte sie direkt in statische Typen konvertieren.
Dieser Pull Request is eher ein PoC, und ich bin neugierig, was eure Sicht ist.

Motivation

Statische Typen zum Parsen der XML Dateien.

Weitere Mögliche Nutzung

Generierung von SQL Statements, um z.B. PostGIS/PostgreSQL Tabellen zu erzeugen.

Was steckt im PR?

• siehe generator.go -> die spec/*.yaml Dateien werden gelesen und Go-Code wird geniert
• siehe example_test.go -> exemplarische Nutzung der generierten Codes/Structs
• siehe spec.go -> Ergänzung um weitere Felder 'description' in der Spec
• spec/AnlagenEegSolar.yaml -> exemplarische Anpassung der description fields
• siehe "die anderen go files" -> auto-generierter code

Vorschlag/Idee

Ich fände es praktisch, das Datenmodell als statische Typen in einem Go module zur Verfügung zu stellen.
Basierend auf dem Generator könnte man ein eigenes Repo erstellen, wo die Specs und die Typen enthalten sind.
Je nachdem, wie wichtig es euch ist, dass die Specs außerhalb des 'mastr' binaries liegen - oder nicht,
könnte man mittels Go -> embedded Filesystem die Specs auch statisch in die Library compilieren,
was die Nutzung in anderen Projekten erleichert - sprich die statischen Typen und die Spec.Yamls
sind in gleicher Version über die Bibliothek verfügbar.

Der PoC zeigt die Kern-Idee und müsste aber für den "produktieven Einsatz"
noch ausgebaut werden. Diese Dinge fallen mir ein und würde ich auch noch implementieren.

Noch zu tun

• "date" typen als native Typen implementieren
• die optionalen Felder als Pointer implementieren (erlaubt NULL in der DB)
• die übrien spec/*.yaml dateien um die descriptions erweitern
• umbau in eigenes Repo - macht aus meiner Sicht Sinn.

Context / FYI

Ich habe in meinem Projekt auch die "Insert-Statements" generiert (partiell als Go-Code),
und nutze von Postgres die Batch-Imports (pg.CopyIn()) weil sie sehr performant sind.

Wenn ihr das für sinnvoll haltet, würde ich mich freuen, wir können hier ein wenig zusammenarbeiten.
Bin gespannt auf euer Feedback.

Grüße
Martin

[curiousleo]

Sehr cool! Verwendest du das nach wie vor?

Tut mir leid, dass das so lange gedauert hat, ist mir irgendwie durch die Filter gefallen -- danke fuer die Muehe und die gute PR-Beschreibung!

Ich werde mir dein PR diese Woche einmal anschauen. Ich koennte mir vorstellen, dass xml.Unmarshal schneller ist als meine selbst gestrickte Dekodierung (XMLReader.Read), dann waere das ein Gewinn fuer den taeglichen Konvertierungsprozess.

Jetzt erstmal wuerde ich wahrscheinlich die YAML-Dateien noch nicht in ein separates Repo packen, einfach, weil es ein bisschen mehr Aufwand ist und ich die Anfrage bisher erst von einer Person (dir!) gehoert habe.

[nitram509]

Hi, es freut mich zu hören, dass dir meine Idee gefällt.
Ich hatte nur ein kleines Projekt rund um das Register und bin aktuell an anderen Themen.
Wenn du noch Fragen zur Idee oder PR hast, bitte gern melden.