[quote=pq,03.10.2006, 20:09]gut, der rechner hat 2 opterons mit je 2GHz.[/quote]
daran könnt es liegen.
ich finde, es bremst ganz schön.

Quote

esskar: ...strats einwürfe sehe ich nicht wirklich als problem an...

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. Ich wuerde mir auch gerne DBIx naeher anschauen, allerdings wuerde ich zum lernen vorerst eher ein paar kleinere Sachen machen, bis ich das Framework beherrsche und mich in die Denkweise eingewoehnt habe.

Quote

pq: ich finde das board momentan sehr unübersichtlich ...

Dem stimme ich zu. Eine bessere logische Aufteilung waere sehr sinnvoll; deshalb habe ich auch mal mit den packages PBoard::Admin bzw. PBoard::Messenger begonnen; mein naechster Schritt waere gewesen, weitere packages einzufuehren. Aber wenn DBIx::Class dies vereinfacht und zusaetzlich ein Fallback auf DBI pur bietet, ist das eindeutig ein Punkt fuer DBIx::Class.

Quote

pq: mir machen eingentlich eher die vielen abhängigkeiten sorgen

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

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

mod_perl vs. CGI: da bin ich sowieso auf dem mod_perl-Weg, von daher wuerde mich der Overhead beim Laden nicht stoeren; und das Poard ist jetzt auch unter CGI nicht wirklich schnell (gerade wenn viele Leute gleichzeitig darauf zugreifen). Und Module muessen dafuer sowieso installiert werden, was wohl eher Rootserver bedeutet. Ich will mir auch schon laenger mal mod_perl2 naeher anschauen, weil man Apache1.3 fuer Rootserver kaum mehr bekommt. Fuer FCGI muss man vermutlich auch den Server umkonfigurieren (habe damit noch keine Erfahrung)

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

<!--EDIT|Strat|1159907105-->

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-->

[quote=pq,03.10.2006, 22:42]
... ich denke, die logik wird dann klarer.
[/quote]
dem stimme ich zu

[quote=pq,03.10.2006, 22:42]
wie willst du dann transaktionssicherheit garantieren?
[/quote]
Indem wir Transaktionen verwenden

[quote=pq,03.10.2006, 22:42]

Quote

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

... zudem kann man das immer noch machen, ... will sagen, der umstieg auf DBIC verhindert nicht den umstieg auf catalyst später.[/quote]
gut.

Dann bin ich auch fuer DBIx::Class ab der zweiten Version.

Sooo, ich war gerade mal wieder auf der dervelop-Version und da sind mir folgende Sachen aufgefallen:

Wenn ich mich eingeloggt habe und ich dann auf einen Thread gegangen bin, war ich scheinbar wieder ausgeloggt.

Und als es dann endlich funktioniert hat, wollte ich mal einen Post löschen und dann habe ich diese Fehlermeldung bekommen:
Couldn't delete message because couldn't update message count:

@renee: danke fuer die hinweise und das "Hallo Wach"

Noch eine Frage: gibt es im Poard eigentlich eine User-Verwaltung, wo Admins (oder vielleicht auch Mods) User löschen können? Wenn man sich nämlich hier mal so die letzten Registrierungen anschaut, könnte man da einiges löschen...

ich glaube noch nicht.
im rahmen meines cms baue ich aber sowas und habe vor, das
auch fuer das poard-model zu bauen. bzw. wird das mein referenz-model.
es beinhaltet auch rollen-management, so dass man
vielleicht auch mal ganz nett rechte verwalten kann (z.b. user,
die schon lange dabei sind, duerfen spam markieren oder so,
damit das nicht immer ein moderator machen muss.)

(edit: oder im gegenteil, anonyme posts werden nur fuer die highlevel-user
sichtbar, und koennen dann approved werden. ungefaehr wie bei perlmonks)\n\n

<!--EDIT|pq|1165845183-->

ich weiss, sowas ist ein bisschen asozial, aber ich habe im rahmen meines CMS
angefangen, das poard neu zu schreiben. da die komplette rechte-verwaltung schon da ist,
brauche ich mich darum nicht zu kümmern, und es setzt auf DBIx::Class auf (ist
aber trotzdem unter CGI auch noch einigermassen schnell genug, da ich lazy-loading mache.
es fehlen noch eine menge funktionen, aber das einbauen einer neuen funktion
geht relativ schnell.
ich habe das datenbank-schema fast genauso übernommen wie im jetzigen poard
(ein paar kleinere änderungen waren notwendig). das dbic-schema habe ich auch
im svn eingecheckt.
ich habe irgendwie keinen zugang mehr zum alten code gefunden; wenn man mal
an DBIC gewöhnt ist, ist SQL im perl-code sowas von umstaendlich =)

wenn jemand sich das mal ansehen will, sagt bescheid

Wenn du HTML::Template::Compiled benutzt, würde ich da gerne mal einen Blick drauf werfen. Habe bis jetzt nur mit TT gearbeitet und wollte HTC zumindest mal in einem größeren Projekt sehen. Außerdem habe ich großes Interesse an einem guten, perlbasierten Forum.