[quote=Strat,02.10.2006, 22:34]Kann DBIx::Class mit unserem DB-Schema umgehen?[/quote]
seltsame frage! :)
aber ja, warum nicht?

[quote=esskar,03.10.2006, 08:04][quote=Strat,02.10.2006, 22:34]Kann DBIx::Class mit unserem DB-Schema umgehen?[/quote]
seltsame frage! :)
aber ja, warum nicht?[/quote]
z.B. Class::DBI haette echte Probleme mit unserem Schema. Ich habe mit DBIx::Class mal rumgespielt, aber es mir noch nicht ernsthaft angeschaut.

Ich habe das Problem, dass meine DBIx::Class-Spielereien schon einige Monate her sind und ich ueberdies vermutlich eine Menge von Class::DBI und DBIx::Class durcheinanderwerfe; ich finde naemlich Class::DBI nur in Ausnahmefaellen verwendbar (gerade weil man da kaum ein schon bestehendes DB-Schema verwenden kann).

[quote=betterworld,03.10.2006, 01:04]
...Ich weiß aber auch, dass Du das Board schnellstmoeglich einsatzbereit haben moechtest ohne vorher größere Schoenheitsaenderungen zu machen....[/quote]
Genau; ich will mal eine erste Version in Produktion haben, denn das jetzige Board nervt nur noch (Paradefall: Registrierung/Suche). Deshalb will ich da keine groesseren Strukturaenderungen mehr, sondern primaer den Messenger fertigstellen und Bugs fixen.

Fuer eine zweite Version sieht es dann voellig anders aus.

Ich habe versucht, eine Gegenueberstellung DBI/DBIx::Class zu finden, aber ziemlich erfolglos. Habt Ihr da zufaellig was?

Ich versuch's selbst mal:

Vorteile von DBIx::Class:
x) Methoden anstelle von SQL
x) Zusaetzliche Abstraktionsschicht
x) DB-Schemabereinigung koennte man gleich mitmachen (Feldschreibweisen vereinheitlichen, manche Spalten "ausmisten")
x) Spassfaktor, ein neues Framework zu lernen

Nachteile von DBIx::Class:
x) Man hat das SQL nicht mehr direkt vor Augen
x) Den Umstellungsaufwand nach DBIx sehe ich eher hoch (laut esskar eher nicht)
x) Wir haben noch wenig Erfahrung mit DBIx::Class (ausser esskar, aber der hat keine Zeit)
x) Zeitfaktor, ein neues Framework zu lernen + typische Anfaengerfehler

Seht ihr die Punkte auch so? Habt ihr weitere Punkte?\n\n

<!--EDIT|Strat|1159880930-->

> Wir haben noch wenig Erfahrung mit DBIx::Class

geht schon; ich hab genug, aber keine zeit

> Den Umstellungsaufwand nach DBIx sehe ich eher hoch

eigentlich nicht

Habe weitere Punkte oben hinzugefuegt

[quote=esskar,03.10.2006, 15:00]> Wir haben noch wenig Erfahrung mit DBIx::Class

geht schon; ich hab genug, aber keine zeit
[/quote]
grins

[quote=esskar,03.10.2006, 15:00]
> Den Umstellungsaufwand nach DBIx sehe ich eher hoch

eigentlich nicht[/quote]

Da zumindest ich noch wenig Ahnung von DBIx::Class habe, ist die Gefahr gross, einige typische Anfaengerfehler zu begehen, die eine Menge Zeit kosten. Naja, wenn ich am Mittwoch wie geplant im Lotto gewinne, habe ich zumindest eine Menge Zeit ;-)\n\n

<!--EDIT|Strat|1159881001-->

möchte noch was hinzufügen:
ich finde es falsch, DBIx::Class und DBI gegenüberzustellen als zwei
alternativen. DBIx::Class setzt auf DBI auf, und mit DBIx::Class hat
man immer noch die möglichkeit, SQL selbst zu schreiben und auch
das DBI-objekt zu benutzen.

ich finde das board momentan sehr unübersichtlich. große teile
bestehen aus dem zusammenbasteln von SQL. das ist fehleranfällig,
und fördert wiederholung von code. das, was eigentlich an logik
passiert, wird von langen string-konkatenationen unterbrochen.

zudem gibt es subroutinen, die IMHO falsch angesiedelt sind und
in andere packages gehören. mit der einführung von DBIx::Class
könnte man hier aufräumen und methoden, die zum user gehören, auch
in das entsprechende package packen.

mir machen eingentlich eher die vielen abhängigkeiten sorgen; jeder
von euch hat bestimmt schonmal erlebt, dass CPAN bei rekursiven
installationen abbricht, weil ein test fehlschlägt. d.h. die installation
des boards wird für leute, die nicht jeden tag mit CPAN umgehen,
evtl. etwas langwieriger.

im grunde von ich für DBIx::Class.
was in meiner ansiucht dagegen spricht (strats einwürfe sehe ich nicht wirklich als problem an):
* das interface ist für transaktions datenbanken geschrieben (es gibt (noch) keine funktion, um beispiels weise eine tabelle zu locken)
* es kann nicht mehr unter CGI laufen (da der Startup ziemlich lange dauert (auch ohne Loader))\n\n

<!--EDIT|esskar|1159889347-->

[quote=esskar,03.10.2006, 17:27]* es kann nicht mehr unter CGI laufen (da der Startup ziemlich lange dauert (auch ohne Loader))[/quote]
bist du sicher?
mag sein, dass es über CGI langsamer ist, aber soo langsam nun auch
nicht... lauffähig dürfte es auf jeden fall sein.
bei mir läuft ein beispiel-script mit DBIx::Class und 6 tabellen im schnitt
0.6 sekunden. gut, der rechner hat 2 opterons mit je 2GHz.\n\n

<!--EDIT|pq|1159899020-->

@strat: kannst du bitte lib/Messenger.pm noch einchecken? danke =)

[quote=pq,03.10.2006, 21:37]@strat: kannst du bitte lib/Messenger.pm noch einchecken? danke =)[/quote]
@pq: ist erledigt; sorry