Wikipedia Diskussion:Mentorenprogramm/Versionswechsel/Archiv

@Ulli: Kannst du bitte mal ein Datenbank-Dump in einem offenen Format erstellen, wenn das einigermaßen geht, und auf deinen Server zur öffentlichen Verfügung stellen? Dann würde ich mir das nämlich mal runterladen und die Datenbank-Struktur anschauen. Grüße, --ireas Diskussion // Bewertung 22:08, 27. Mai 2010 (CEST)

...lesbare (und sinnvolle) dumps bitte bei Euku erfragen! lg, --NB/archiv _MP-DB 22:21, 27. Mai 2010 (CEST)

Hier mein erster (vollkommen unverbindlicher und unfertiger) Vorschlag, nur damit Ihr seht, in welche Richtung es gehen könnte. Grüße --Carport ^{(D i s k) (±)} 20:05, 28. Mai 2010 (CEST)

...sieht gut aus - die richtung stimmt schon! lg, --ulli purwin _fragen? 22:53, 28. Mai 2010 (CEST)

Find ich auch! :) Ich melde schon mal an, dass auch <p class='error'>Fehlermeldung</p> vorkommen wird, d. h. ein Styling für .error wäre schön. :) --ireas Diskussion // Bewertung 09:19, 29. Mai 2010 (CEST)

theoretisches Grundkonzept

• es fängt auf Wikipedia an: mit
  • zwei kategorien (+ einer temp. hilfskat.), der "Neulingsbörse"(NB) und den Archiven

• es wird zwischenzeitlich extern ausgelagert: dort
  • in eine db eingespeist (durch Bots und/oder die mentorenlogin-scripte) und aufbereitet
  • byproduct: eine "homepage des MP"...

• es kommt zur Wikipedia zurück: via
  • denselben bot, der es wieder an NB+Archiv "übergibt". Wikipedianer merken es garnich wirklich - es ist (edv-mässig)
  • transparent für den user...

(dieses konzept gilt es grundsätzlich zu dikutieren! denn diese idee stand von vorneherein hinter allem...)

das alt-konzept CF...

...beruhte zunächst auf dem online-quelltext-parsing der beiden WP-Spezialseiten

• mentoren-kat mit PAGESINCATEGORY
• und der neulinge-kat...

meine frage an die PHP-nerds: wie lautet die entsprechende derzeitige PHP5-abfrage auf sowas? würde mir eine längere suche im kompendium ersparen ;) ... danke i.v. --ulli purwin _fragen? 18:22, 31. Mai 2010 (CEST)

Der identische Wert auf die wikipedia-DB (DB-Server: dewiki-p.db) wäre "SELECT cat_pages FROM dewiki_p.category WHERE cat_title = 'Benutzer_ist_Mentor'". Dies ist der gecachte Wert, der dort angezeigt wird und Euku schon mehrfach hat verzweifeln lassen.

Ansonsten würde ich "SELECT COUNT(*) FROM dewiki_p.categorylink WHERE cl_to = 'Benutzer_ist_Mentor'" empfehlen. Damit enfällt das Cache-Problem. Merlissimo 18:37, 31. Mai 2010 (CEST)

...vielleicht hab ich mich bloß mal wieder mißverständlich ausgedrückt:

was ist das PHP-pendant zum CF-parsing:

ColdFusion:

• <CFHTTP METHOD="GET" URL="http://de.wikipedia.org/w/index.php?title=Spezial:Kategorien&dir=prev&offset=Benutzer_ist_inaktiv&limit=1"><CFSET mentores = REFind("Benutzer ist Mentor", CFHTTP.FileContent)><CFSET zahl2 = Evaluate(mentores+46)>

...dies führt zu besagtem quelltext, genau an die stelle, wo die mentorensumme in klammern (99) genannt wird, und das kann ich dann speichern, bzw. auch direkt ausgeben mit:

• <CFOUTPUT>#Mid(CFHTTP.FileContent, zahl2, 3)#</CFOUTPUT>

(müsste irgendwas mit "Get_File()" oder "url" oder so sein...!) lg, (wir sind hier jetzt nicht im sql-bereich!) --NB/archiv _MP-DB 21:36, 31. Mai 2010 (CEST)

Doch! Die HTTP-Abfrage inklusive Parsen ist irrelangsam. Wieso nehmen wir nicht die Daten, die wir eh schon haben, nämlich in der Datenbank? → Merlissimos SQL Abfrage verwenden. Das ist einer der Toolserver-Vorteile. :) Übringes kannst du davon ausgehen, dass du eine Objekt $db hast, das den Datenbankzugriff regel (vgl. Quellcode). Du musst nur das Page-Interface implementieren, vgl. z. B. ViewPage und view.html. Grüße, --ireas Diskussion // Bewertung 21:40, 31. Mai 2010 (CEST)

...also wenn son simples parsing PHP zeitprobleme macht, kann ich schon verstehen, warum es überzeugte CF-user gibt: sowas hat bei mir noch nie gedauert! der hier immer wieder zitierten "objektorientierung" setze ich mal polemisch "prozessorientierung" gegenüber ;))) !

lg, --NB/archiv _MP-DB 22:32, 31. Mai 2010 (CEST)

Das ist ein Missverständis: Der HTPP-Request braucht sowohl in ColdFusion als auch PHP Zeit; und das Parsen ist nicht sehr schön. ;) --ireas Diskussion // Bewertung 22:35, 31. Mai 2010 (CEST)

....das parsen einer solchen mini-seite (wie der oben beschriebenen) liegt im millisekundenbereich - und deshalb hatte sich bislang auch niemand über wartezeiten beschwert. leider bist auchz du nicht bereit, mir endlich diesen entsprechenden PHP-code zu verraten...

iss der jezz 'geheim', oder kennst du ihn bloß nich ;) ? fragt --NB/archiv _MP-DB 22:44, 31. Mai 2010 (CEST)

Aber eine kleine DB-Abfrage ist schneller als ein HTTP-Request … Naja, wenn’s denn sein muss. ;) Das Ganze geht via cURL, ein Beispiel siehst du hier. Grüße, --ireas Diskussion // Bewertung 22:49, 31. Mai 2010 (CEST)

...danke dir, Ireas! so'n oller knacker wie ich braucht halt ab und an einen link - sonst müsste der ja kompendien wälzen. aber je länger ich mir diese cURL-functions anschaue, umso mehr scheint es auf das herunterladen einer kompletten homepage = "spidern" rauszulaufen - das meinte ich natürlich nicht! sondern lediglich das herunterladen des quelltextes einer einzelnen seite (die hier z.b. überhaupt nur 6 zahlenwerte plus linefeeds enthält): Euku's SpBot macht sowas bei mir im 20-min.-abstand.... lg, --NB/archiv _MP-DB 17:38, 1. Jun. 2010 (CEST)

Das ist in php so - einige lieben curl, andere nicht. Die einfache Variante ohne sieht so aus (in dem Fall per API):

<?php
  ini_set('user_agent', 'MyBot');
  $ret = file_get_contents('http://de.wikipedia.org/w/api.php?action=query&prop=categoryinfo&titles=Kategorie:Benutzer%20ist%20Mentor&format=php');
  $catinfos = unserialize($ret);
  $catinfo =  array_shift($catinfos['query']['pages']);
  echo 'Catcount:' .  $catinfo['categoryinfo']['pages'] . "\r\n";
?>

Merlissimo 19:29, 1. Jun. 2010 (CEST)

...genau dat war's: fgetc() - sowas einfaches meinte ich... danke dir! lg, --NB/archiv _MP-DB 00:48, 2. Jun. 2010 (CEST)

Grundkonzept PHP

Kleine Ankündigung: Ich bastele gerade lokal an einem Grundkonzept für die Seite und werde das dann demnächst online stellen. Grüße, --ireas Diskussion // Bewertung 11:27, 29. Mai 2010 (CEST)

Dazu: Ich würde das Ganze nicht einfach eins zu eins machen, d. h. ein CF-Skript zu einem PHP-Skript, sondern eher PHP-like, d. h. objektorientiert. Mein Entwurf ist, wie gesagt, spätestens am Montag online. Grüße, --ireas Diskussion // Bewertung 20:13, 29. Mai 2010 (CEST)

...hatte ich auch nich wirklich vor. ich versetze mich damit halt nur künstlich in die anfangszeit zurück: remember ;) ? ...damit hatte vor fast drei jahren alles mal angefangen, und wurde auf dieser basis gemeinschaftlich weiterentwickelt. eigntlich kein verwerflicher ansatz, das rad nich zum zweitenmal erfinden zu wollen... :)) lg, --NB/archiv _MP-DB 20:33, 29. Mai 2010 (CEST)

p.s.: mir fällt bei dem vergessenen link grade auf, dasses (trotz vierfachen quelltext-parsings!) dennoch säuisch schnell lief ;) ... die verzögerung heutzutage resultiert nur aus der vergeblichen suche nach der "listenversion der hilfe-gesucht-kat", die wir damals noch hatten, sowie einer inzwischen verstorbenen datei namens "helpseek.txt" (LastUpdate: vor vielen monaten)...

So, das Projekt ist da: tools:~dewpmp. Gleich mehr. ;) --ireas Diskussion // Bewertung 17:56, 30. Mai 2010 (CEST)

Kannst du die Webseite im SVN in ein Unterverzeichnis (z.B. /web) verschieben. Dann hätte ich Platz für meine Skripte, die nichts mit dem Web zu tun haben und es bleibt übersichtlicher

Aus Sicherheitsgründen sollten Scripte, die der Besucher nicht aufrufen soll auch nicht aufrufbar oder lesbar sein. Man kann natürlich überall die Rechte pflegen und entsprechend setzen. Mein Vorschlag wäre ein anderer, der zu deinem Konzept passt: Alle Webscripte nach unterhalb von ~/web schieben und in ~/public_html nur die index.php, die stattdessen dann ../web/include/main.php included. Nur Bilder und Styles bleiben noch im öffentlichen Bereich. Merlissimo 07:29, 31. Mai 2010 (CEST)

Gut, ich versuche mich drum zu kümmern. ;) Ansonsten kannst du das auch gerne machen, du bist in der Gruppe dewpmp. Grüße, --ireas Diskussion // Bewertung 14:57, 31. Mai 2010 (CEST)

Grundkonzept DB

Ich habe mir die DB-Struktur angeschaut. Ein paar Dinge sind dort nicht optimal gelöst. Man kann gut erkennen, wie das Projekt im Laufe der Zeit gewachsen ist und zu einem Kern dann immer ein neues Datenbankfeld hinzugefügt wurde. Die jetzige Neuauflage bietet eine einfache Möglichkeit sich um ein neues Datenbanklayout Gedanken zu machen, das den Objektbeziehungen entspricht. Hört sich jetzt nach viel an, da man die Queries in allen Skripten ändern muss, aber eben auch nicht mehr (besonders nicht die Ausgabe). Es sind ja auch nur zwei Tabellen. Der Aufwand ist insgesamt gering.

In der Übergangzeit kann man auch Views erstellen, damit die alten Queries ebenfalls funktionieren. Ich kann die dann von Zeit zu Zeit durchgehen und korrigieren. Vorteil wäre, dass sich die Datenbankstruktur nicht mehr an den Ausgabe-HTML-Seiten orientiert, sondern an den Objektbeziehungen. Das ganze würde ireas php-Objektumsetzung einfacher gestalten und etwas mehr Möglichkeiten für die Zukunft bieten. Die ganzen Datentypen müssen eh geändert werden, da dies bei Access andere waren und bei der Erstellung des Dumps natürlich ein Datentyp gewählt wurde, der den Access-Typ komplett enthält. Die Felder würde ich einheitlich klein mit Unterstrich benennen, wie in der DB-Welt üblich. Zudem ein einheitlicher Feld-Präfix, damit man auf Aliase in den Queries verzichten kann. (entspricht auch der mw-Benennungstruktur)

Zudem sollten wir das ganze nach daphne (bzw. besser den alias dewiki-p.db benutzen) verlagern (ireas hatte es auf sql (adenia) aufgespielt).

Ich habe eben schon damit angefangen (Vor allem wegen der Zeichensatzkonvertierung). Allerdings hätte ich noch ein paar Fragen:

1. Wer benutzt die wp_scrollbox_ID bzw. wodurch wird der Wert definiert? (Reihenfolge im Wikitext ist es nicht ;-) )
2. neulinge_SUCHNAME/mentoren_SUCHNAME ist wofür gedacht? (Ich vermute es entfällt bei utf8-only)
3. Was bedeuten die Werte x,i,b,- in mentoren_status bzw a,w in neulinge_status (inaktiv und archiviert kann ich mir noch erdenken)
4. Wann wird ein neuling deleted
5. Wollen wir deutsche oder englische Bennenungen (im Moment deutsch mit englischen "einflüssen")
6. In vielen Fällen entspricht neulinge_gesamt nicht der Anzahl zugeordneter Neulingen. Wo der Wert größer ist könnte man es sich z.B. durch Mentorenwechsel erklären. Aber in vielen Fällen ist die Zahl sogar kleiner. Wie kommt das zustande? Wäre es nicht sinnvoll genauer zu speichern, wer wen wann betreut hat?

Merlissimo 07:29, 31. Mai 2010 (CEST)

Gefällt mir gut. Ich würde englische Bezeichner nehmen und mentor als englisches Wort verwenden, da ich nicht weiß, ob es da eine gescheite Übersetzung gibt. Für Neuling würde ich newbie vorschlagen, der Rest dürfte eindeutig sein. Ansonsten muss ich ankündigen, dass ich vermutlich die nächste Zeit wenig machen werde, da mein Rechner streikt und meine Daten mit sich ins Nirvana gezogen hat. :-/ --ireas Diskussion // Bewertung 11:11, 31. Mai 2010 (CEST)

@merl:

ich gebe dir recht mit dem gewachsenen flickenteppich - da gibts sicher vieles zu optimieren. wir hatten ja auch mehrere strukturelle änderungen im MP - diese ganze debatte darüber kann man im disku-archiv nachlesen - woraufhin auch db-änderungen vorgenommen werden mussten, weil das in unsere richtlinien einfloss. es ging halt drum, das ganze weiter funktionsfähig zu belassen...

zu deinen fragen:

1. die scrollbox-ID erfasst alle mentoren und wird additiv erzeugt, sobald ein neuer mentor in diese "scrollbox" auf der hauptseite sich einträgt und danach auch wirklich wenigstens einen mentee aufweist. daher entspricht 'Max.scrollbox_ID' auch der konkreten mentorenanzahl ('b'+'i'+'x'+'-') und wird in allen scripten benötigt, welche gesamtüberblicke zeigen. die 'MID', also der eigentliche DB-primarykey, wird (da unik) zur direkten einzeldarstellung rangezogen. 'Max.wp_mentoren_ID' iss kleiner alsw 'SID', weil es anfangs etliche löschungen von schein-mentoren(ohne mentees) und später auch löschungen bzw. wiedereintragungen gab. in der tabelle kann man auch gut nachvollziehen ab wann diese neuerung griff: nämlich seit HAL (MID:67 / SID:51). von da an ist diese scrollbox_ID identisch mit dem 'wp_mentoren.RecordCount'. dusiehst: schon diese simple frage berührt ne menge "ideologisches" ;) ...

2. der SUCHNAME wurde genau deshalb eingeführt, weil utf8 in der sortierung so scheisse iss ;) : das wurde spätestens notwendig, als 'ßefer' oder 'Äbälafuchs' ganz am schluß der zweiten seite hinter 'Zydney.jk' in der kategorie einsortiert wurden! besonders wichtig im script unser '4-fach-check' bei der schnellen suche nach fehlern... jeder vernünftige mensch zieht (zumindest in Deutschland!) eher eine art 'telefonbuch-' oder eine 'lexikalische sortierung' vor!

3. mentoren_status/neulinge_status:

• "-" = neu kategorisierter mentor, noch ohne mentees (->Kategorie:Benutzer ist Mentor)
• "a" = aktiv; hat mentees (->"Neulingsbörse")
• "i" = aktiv; nur z.zt. inaktiv - hatte also schon mentee(s)
• "x" = ex-mentor; hatte aber mentees (->"Archiv(e)")
• .
• "w" = mentee wurde ins MP aufgenommen (->"Kategorie:Wird im Mentorenpramm betreut")
• "a" = mentee wurde bereits archiviert - wichtig für zweit-mentierungen!(ID bleibt erhalten)

(die temporäre hilfskategorie "Mentor gesucht" erscheint also garnicht in der db)

4. das feld 'deleted' ist gebunden an infinit gesperrte oder auf eigenen wunsch deaktivierte ex-neulinge. war mal geplant, um unmögliche weiterleitungen im kontext auzuschalten

5. lieber englische: vielleicht wird's dann auch von "en_wiki:Adopt-a-User" kopiert ;) !

6. über den letzten punkt müssen wir genauer sprechen: bislang galt die regel

• jeder mentee hat einen mentor(und zwar den zuletzt aktiven). ein freimütiges anbieten von "wechselt doch soviel und sooft ihr wollt" haben wir stets durch die beschreibungen des MP im eingangsbereich kurz gehalten: wenn einer schonmal betreut wurde, sollte der sich eigentlich besser hinterher bei seinem ex-mentor auf der disku melden, und nich schon wieder rein ins MP...

...insgesamt wäre noch mal zu betonen, daß die db alleine nicht alles ist: die muß vor allem dem "workflow" dienen. und grundlegende änderungen daran müssten in jedem fall ausgiebig mit der gesamtmentorenschaft abgesprochen werden - sonst würde es 'diktatorisch' ;) !

so, ich hoffe das wichtigste beantwortet zu haben... lg, --ulli purwin _fragen? 17:45, 31. Mai 2010 (CEST)

Unter Flickenteppich verstehe (und kenne) ich wirklich was anderes. Hier ist es einfach ein gewachsenes Projekt und es ist völlig normal, dass man nicht bei jeder kleinen Erweiterung alle anderen Skripte abändern möchte. Würde man dies machen kostet das soviel Zeit, dass man zu nichts anderem mehr käme. Es bietet sich hier nur gerade eine Gelegenheit, die man nutzen sollte.

Der Unterschied zwischen "auf eigenen wunsch deaktiviert" und "entlassen/archiviert" ist mir noch nicht klar. Alles andere is beantwortet. Ich denke mir mal was aus. Merlissimo 18:30, 31. Mai 2010 (CEST)

...danke für dein verständnis, merl! was sich dahinter versteckt iss doch klar: es soll niemand (weder mentee noch mentor) gebrandmarkt werden! die suchfunktion würde es möglich machen... das (für mentoren durchaus sinnvolle ergebnis) erscheint dann anonymisiert in der statistik: derzeit (66+12) mentees...

Neue DB-Struktur ist seit letzter Nacht aktiv und in Benutzung. Konvertierungsskript läuft ohne Probleme (außer der einen Benutzernumbenennung). Die Erstellung der Tabellen und der Datenimport aus der Dump-Datei mit alter Struktur dauert etwa eine Minute. Hier der Code, der das Schema erstellt. Merlissimo 16:54, 1. Jun. 2010 (CEST)

neues DB-Schema

CREATE TABLE IF NOT EXISTS mentor(
 mentor_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 mentor_user_id INT UNSIGNED NOT NULL UNIQUE KEY COMMENT 'user.user_id',
 mentor_user_name VARCHAR(255),
 mentor_user_name_normalized VARCHAR(255),
 mentor_login_name VARCHAR(255),
 mentor_login_password CHAR(40) COMMENT 'SHA1 HEX',
 mentor_in DATE,
 mentor_out DATE DEFAULT NULL,
 mentor_is_active TINYINT(1) UNSIGNED,
 mentor_scrollbox_id INT UNSIGNED,
 mentor_scrollbock_text TEXT,
 mentor_has_barnstar TINYINT UNSIGNED,
 mentor_award_level TINYINT UNSIGNED COMMENT '1=bronze,2=silber,3=gold,4=platin,5=smaragd',
 mentor_remark VARCHAR(255),
 mentor_lastupdate TIMESTAMP,
 INDEX(mentor_user_id),
 INDEX(mentor_login_name),
 INDEX(mentor_is_active)
);
CREATE TABLE IF NOT EXISTS mentee(
 mentee_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 mentee_user_id INT UNSIGNED NOT NULL UNIQUE KEY COMMENT 'user.user_id',
 mentee_user_name VARCHAR(255),
 mentee_user_name_normalized VARCHAR(255),
 mentee_in DATE,
 mentee_out DATE DEFAULT NULL,
 mentee_is_hidden TINYINT UNSIGNED,
 mentee_remark VARCHAR(255),
 mentee_lastupdate TIMESTAMP,
 INDEX(mentee_user_id),
 INDEX(mentee_is_hidden)
);

CREATE TABLE IF NOT EXISTS mentee_mentor (
 mm_mentee_id INT UNSIGNED,
 mm_mentor_id INT UNSIGNED,
 mm_start DATETIME,
 mm_stop DATETIME,
 INDEX(mm_mentee_id),
 INDEX(mm_mentor_id)
);

CREATE TABLE IF NOT EXISTS comentors(
 co_mentor_id INT UNSIGNED,
 co_comentor_id INT UNSIGNED COMMENT 'mentor.mentor_id',
 PRIMARY KEY(co_mentor_id,co_comentor_id),
 INDEX(co_mentor_id),
 INDEX(co_comentor_id)
);

CREATE TABLE IF NOT EXISTS mentee_articles(
 ma_mentee_id INT UNSIGNED,
 ma_page_id INT UNSIGNED UNIQUE KEY COMMENT 'page.page_id',
 ma_rev_id INT UNSIGNED UNIQUE KEY COMMENT 'revision.rev_id',
 ma_creation_date DATETIME
);

zu sog. 'ideologie' des mp

...zugegebenermaßen richten sich viele vorstellungen des alten konzepts danach aus:

• ungeschriebene gesetze, wie "kein mentor ohne mentee", "keine zwangs-betreuung" (d.h. vollständige freiwilligkeit auf beiden seiten!) usw. und deshalb: bitte alle bisherigen richtlinien nochmal durchlesen!

• die wichtigkeit einer art "homepage des MP" mit optimaler selbstdarstellung - war wieschongesagt damals nur extern möglich. sollte aber zumindest in ihrer funktionalität und dem damit verbundenen informationsgrad unbedingt beibehalten werden - sonst wäre es eine verschlechterung des bisherigen. man sollte nicht vergessen, daß die alte DB seit nunmehr 32 monaten überraschend schnell, sowie (fast) fehler- und ausfallsfrei läuft - dies gilt es zu toppen! denn diese DB trug auch entschieden zur allgemeinen akzeptanz des MP bei...

• ein wichtiger punkt wäre dabei auch die fortführung und weiterentwicklung der "neueren features": zum besten dabei gehörten

1. recht perfektionierte einzelseiten wie [nnn mentoren] auf der db-startseite erreichbar (da gibts noch mehr beispiele) oder
2. die direktsuche im index-rahmen : (sehr ähnlich auch auf ([http://purwin.de/WP_PB/TAXman.cfm ->WP:PB) - macht einfach spaß, es zu benutzen... und
3. eine klare ausrichtung auf sog. 'datenblätter' für mentees und mentoren, mit den wichtigsten angaben(ohne den datenschutz zu gefährden) sowie
4. die verknüpfung mit anderen tabellen (admins, PB, Beitragszahlen) zu welchen die betroffenen auch ihre zustimmung gaben (im zweifelsfall könnte jeder einzelne auf wunsch auch rausgenommen werden!)

....das problem der portierung nach PHP steigt hier allerdings - da brauch ich echt hilfe - bin mehr der CF-typ(um mit Tilla zu sprechen ;) !)

lieben gruss, --NB/archiv _MP-DB 22:20, 31. Mai 2010 (CEST) (früher mal versehentlich als Bot angesehen)

Musst du ja auch nicht alleine machen. ;) Ich knöpf mir demnächst Seite für Seite vor. Grüße, --ireas Diskussion // Bewertung 22:06, 31. Mai 2010 (CEST)

...alles klar: ich bereite es schonmal vor. sobald der angegebene info-grad mit dem neuen erreicht sein sollte, käme endlich auch Carport ins spiel - mit einem zeitgemässen look&feel !

lg, --NB/archiv _MP-DB 22:26, 31. Mai 2010 (CEST)

Ich habe Carport schon um einen Vorabentwurf gebeten, damit das nicht so trist aussieht. ;) --ireas Diskussion // Bewertung 22:28, 31. Mai 2010 (CEST)

...bitte trag dich oben ein mit sig - so wie alle anderen auch... lg, --ulli purwin _fragen? 02:25, 8. Jun. 2010 (CEST)