[Munich-pm] Elche einfrieren - oder: Alle Wege führen nach ORM

[Harald Jörg]

Hallo Mongers,

Heute habe ich ein paar Fragen (ein Sommerrätsel) und ein Angebot.

in den letzten Wochen habe ich an etwas rumgebastelt, bei dem ich mir
nicht vorstellen kann, dass ich der erste bin. Auf CPAN gibt's entfernte
Verwandschaft, aber nicht das, was ich möchte...

Es fing damit an, einen Sack von Excel-Dateien zu parsen... dann kam
eine XML-Datei dazu, dann ein bisschen Workflow.  Am Anfang habe ich
immer alles "von Null" aus den Dateien aufgebaut, nur irgendwann war's
mir zu dumm, alle Abfragen einfach auszuprogrammieren und ich wollte das
in eine Datenbank packen, damit die Kollegen direkt per SQL drauf
losgehen können.  Also: Ein Object-Relational-Mapper muss her, der aus
meinen Objekten Datenbank-Tabellen macht.

Hm. "Da nimmt man DBIx::Class", heißt es.  Nur ist der falschrum: Da
muss man erst das Datenbankschema haben, und er erzeugt die Objekte
draus.  Also eigentlich ein ROM und kein ORM. Ich habe auch kurz über
Tangram, Fey und Alzabo geblättert, aber die scheinen alle genauso
gestrickt zu sein: Erst baut man das Schema nach deren Regeln.  Eine
Ausnahme ist KiokuDB, aber der packt die Objekte in JSON-Strings - wenn
ich echte Datenbankabfragen auf einzelne Attribute machen will, muss ich
wieder die Spalten extra abspeichern.

    Ich habe Moose-Klassen, bei denen jedes Attribut Auskunft geben
    kann, wie man's abspeichert.  Und ich will jedes Attribut in Queries
    verwenden können, was die KiokuDB praktisch ausschließt.

Ich bin grade dabei, das selber zu machen: Per Introspection die
Moose-Attribute abfragen, daraus die Datenbank-Spalten erzeugen.  Wie
bei den anderen ORMs kann es sein, dass ein Objekt mehrere Tabellen
erzeugt, beim ersten "echten" Testobjekt sind es deren 19.  Das macht
Spaß, wird aber umso länglicher, je mehr Möglichkeiten von Moose man
unterstützen will.

Nun die Fragen:
   * Kennt einer von Euch ein vergleichbares Projekt auf CPAN, das ich
     übersehen habe - oder habe ich eins der genannten einfach falsch
     verstanden?

   * Anstelle direkter SQL-Tabellen könnte ich auch ein
     DBIx::Class-Schema erzeugen und daraus dann die Tabellen
     generieren.  Das ist mehr Aufwand, aber die DBIx::Class-Fans
     könnten dann direkt mit dem Schema arbeiten und müssten kein SQL
     verwenden.  Ich habe überhaupt kein Gefühl dafür, ob DBIx::Class
     einfach nur eine von vielen Möglichkeiten ist oder der
     "Perl-Standard". Wie seht Ihr das?

Das Angebot:
   * Wir hatten schon lange keine technische Session mehr.  Wenn
     Interesse besteht, dann kann ich mal vorstellen, was ich da gebaut
     habe, was alles geht und wo die Grenzen sind.
-- 
Cheers,
haj