Quote

Das sind keine Einwaende, sondern ich versuche herauszufinden, welche Vorteile ein Umstieg auf DBIx bringt; aber da kam bisher leider nur wenig Feedback von euch.

naja, es eliminiert die nachteile der jetzigen lösung.
man braucht sich nicht darum zu kümmern, in welcher tabelle welche
daten liegen, und wie die felder heißen. zum updaten muss man
einfach nur ein objekt speichern. ich denke, die logik wird dann klarer.

Quote

Mir auch ein wenig; DBI gibt's fast schon ueberall; fuer Windows (fuer Spezialisten fuer mich, die sinnloserweise sogar mod_perl unter Windows betreiben) gibt's auch eine Menge an DBIx-Modulen via ppm (leider nicht DBIx::Class:Schema::Loader). Aber fuer Linux habe ich auch keine vernuenftige Loesung

naja, an sich lässt sich ja alles mit der cpan-shell installieren.
nur halt mit evtl. auftretenden fehlern kann man als erfahrener cpan-benutzer
besser umgehen.

Quote

(Noch?) fehlende Locks: wenn man die Tabellen ein wenig umbaut, koennte man vermutlich auf Locks verzichten...

wie willst du dann transaktionssicherheit garantieren?

Quote

Und Module muessen dafuer sowieso installiert werden, was wohl eher Rootserver bedeutet.

ich hab das board wie gesagt auf meinem webspace laufen, und im
prinzip lässt sich alles per cgipan installieren. gut, eine shell kann
ganz nützlich sein, aber es muss keine root-shell sein, um das board zum laufen zu bringen.

Quote

Wenn ich den Gedanken DBIx weiterfuehre, frage ich mich, ob nicht gleich der Umstieg auf Catalyst Sinn macht...

hmm, aber catalyst ist ja nicht der nachfolger von DBIC.
zudem kann man das immer noch machen, denn wenn das db-schema
mal steht, braucht man das nicht zu ändern, wenn man catalyst
hinzufügen will. will sagen, der umstieg auf DBIC verhindert nicht
den umstieg auf catalyst später.\n\n

<!--EDIT|pq|1159908236-->