Id-urile pentru utilizatori sunt numere, dar restul sunt VARCHAR (64) cu niste validari facuta in cod prin regex-uri. Ar fi mai bine sa avem toate id-urile drept numere, spre exemplu task_id int si task_name string. task_name se poate obtine foarte usor din task_id adaugand un join trivial.
MySQL *nu* face 'index pe hash-uri':http://dev.mysql.com/doc/refman/5.1/en/create-index.html pentru tabele pe disc (doar pentru tabele din memorie). MySQL sorteaza id-urile alfabetic tinand cont de colatii (latin2 pentru noi). Tinand string-uri peste tot crestem dimensiunile tabelelor, iar asta este oribil pentru tabele de genul ia_score sau ia_job. S-ar merita de facut niste teste de performanta, se poate compara un tabel de scor exclusiv numeric cu unul plin de string-uri.
MySQL *nu* face 'index pe hash-uri':http://dev.mysql.com/doc/refman/5.1/en/create-index.html pentru tabele pe disc (doar pentru tabele din memorie). MySQL sorteaza id-urile alfabetic tinand cont de colatii (latin2 pentru noi). Tinand string-uri peste tot crestem dimensiunile tabelelor, iar asta este oribil pentru performanta tabele de genul ia_score sau ia_job. Aici s-ar merita de facut niste teste de performanta. Spre exemplu putem compara un tabel de scor exclusiv numeric cu unul plin de string-uri.
h3. Tabele de wiki: ia_textblock, ia_textblock_history, ia_file.
Tabelele ia_textblock si ia_textblock_histor au aceasi structura, doar ca ia_textblock tine ultima versiune. Asta inseamna ca orice fel de istorie are nevoie de query-ul complicate pe baza de UNION. Ar trebui sa tinem un singur tabel, eventual cu un tabel aditional care duplica doar datele cele mai recente.
Ultima versiune a unei pagini de wiki se tine in ia_textblock, iar versiunile precedente se tin in ia_textblock_history cu aceasi structura. Asta inseamna ca orice fel de istorie are nevoie de query-uri complicate folosind UNION. Ar trebui sa tinem un singur tabel, eventual cu un tabel aditional care duplica doar datele cele mai recente.
Atasamentele sunt un sistem distict, sunt fisiere pe disc sub-ordonate unui textblock din baza de date. Manipularea atasamentelor este FOARTE neplacuta, si pot aparea desincronizari in diverese locuri. Securitatea atasamentelor depinde de cea a textblock-urilor (si indirect a problemelor) in moduri complicate si imprevizibile. Ar fi mai bine sa avem un singur suport de "BLOB-uri" versionate.
Atasamentele sunt un sistem complet distict, sunt fisiere pe disc sub-ordonate unui textblock din baza de date. Manipularea atasamentelor este FOARTE neplacuta, si pot aparea desincronizari in diverese locuri. Securitatea atasamentelor depinde de cea a textblock-urilor (si indirect a problemelor) in moduri complicate si imprevizibile. Ar fi mai bine sa avem un singur suport de "BLOB-uri" versionate.
Nu avem suport de redenumire si stergere care sa pastreze istoria, si nici o idee resonabil de design care ar permite asa ceva in baza de date. Trebuie investigat daca se poate folosi subversion in loc de MySQL pentru fisiere versionate.
h3. Securitatea, si magia din wiki
Pe parcursul dezvoltarii infoarena2 ne-am dorit sa evitam pe cat posibil functionalitatea "magica" din wiki, si am mers prea departe. Am pornit de la idea ca orice pagina este o pagina de wiki, si paginile de runde sau probleme sunt doar un caz oarecare de pagina wiki. Securitatea paginilor de utilizatori si de probleme trebuie totusi sa fie subordonata problemelor. Noi am realizat asta adaugand un "descriptor de securitate" ca string pentru fiecare pagina de wiki. Pagina problema/adunare are la securitate un string "task: adunare", si asa vizibilitatea paginii depinde de vizibilitatea task-ului. Este un sistem prea generic, incurcat si greu de folosit sau extins.
Pe parcursul dezvoltarii infoarena2 ne-am dorit sa evitam pe cat posibil functionalitatea "magica" din wiki, si am mers prea departe. Am pornit de la idea ca orice pagina este o pagina de wiki, si paginile de probleme/useri/runde/news/blog sunt doar un caz oarecare de pagina wiki. Securitatea paginilor de probleme trebuie totusi sa fie subordonata problemelor. Noi am realizat asta adaugand un "descriptor de securitate" ca string pentru fiecare pagina de wiki. Pagina problema/adunare are la securitate un string "task: adunare", si asa vizibilitatea paginii depinde de vizibilitatea task-ului. Este un sistem prea generic, incurcat si greu de folosit sau extins.
Ar fi mai bine ca orice url de format problema/xxx sa intre prin controller-ul de task-uri, care isi subordoneaza textblock-urile care incep cu problema/xxx. Similar am avea controllere de news, blog, user page care subordoneaza tot ce incepe cu news, blog sau user/costel. Pentru restul paginilor am avea un controler *distinct* de wiki. Codul pentru bucatile de editare si istorie poate fi refolosit in 1000 de moduri, dar nu este acceptabil sa nu poti ajunge de la editarea de enunt la editarea de problema fara sa modifici in address bar.
Ar fi mai bine ca orice url de forma problema/xxx sa intre prin controller-ul de task-uri, care isi subordoneaza textblock-urile care incep cu problema/xxx. Similar am avea controllere de news, blog, user page care subordoneaza tot ce incepe cu stiri, blog sau utilizator/yyy. Pentru restul paginilor am avea un controler *distinct* de wiki. Codul pentru bucatile de editare si istorie a textblock-urile poate fi refolosit in 1000 de moduri. *Nu* este acceptabil sa nu poti ajunge de la editarea de enuntului la editarea limitei de timp fara sa modifici in address bar.
Am avea tabele ia_news, ia_blog_post si ia_wiki care sunt "deasupra" lui ia_textblock, iar ia_textblock ar fi folosit doar pentru versionarea unor bucati de text. Securitatea private/protected/public (care este *foarte* utila si absolut ok) poate fi un simplu enum in ia_wiki. Acel enum trebuie editat folosind un simplu dropdown.
Efortul necesar pentru o astfel de transformare in infoarena2 mi se pare absolut enorm.
Efortul necesar pentru o astfel de transformare in infoarena2 mi se pare iarasi absolut enorm.
h3. Layer de logica
