Ar fi mai bine sa testam functii BL care nu au nici o treaba cu HTTP. Daca BL-ul este ok atunci sigur bug-urile din UI nu pot sa strice nimic in baza. UI-ul se poate testa apoi de mana, sau folosind ceva de genul 'selenium':http://www.openqa.org/selenium/

h3. ia_textblock, ia_textblock_history

h3. Tabele de wiki: ia_textblock, ia_textblock_history, ia_file.

h3. 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.
 
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.
 
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. Caching exagerat

Infoarena2 suporta mai multe forme de caching:
 
# Cache de textile parsat, inainte de executia macro-urilor. Majoritatea request-urilor nu executa codul de textile.
# Cache de imagini redimensionate. Cand se cere o imagine redimensionata ea este salvata pe disc si se evita operatiile de grafic pentru avatari etc.
# Cache de obiecte din baza de date, folosind memcached sau eaccelerator. Acest cache tine obiecte de genul useri, task-uri si runde.
 
Acest ultim mod de caching are inclusiv suport de write-through (cand se salveaza un obiect se sterge cache-ul) care este foarte complex de implementat. Codul de cache este bagat prin foarte multe functii db_ si nu este deloc usor de inteles. Se combinat cod de DB, BL si caching in aceleasi functii.
 
Suportul de write-through nu este de fapt foarte util pentru ca evaluatorul si partea de web nu folosesc acelasi cache. Eventual am fost fortati sa facem rundele sa traiasca doar 5 secunde in cache. Mai mult, acest caching nu imbunatateste mult timpul de raspuns: Am masurat timpii de raspuns cu si fara cache la paginile de enunt si diferentele erau nesemnificative. Acest cod de caching complica mult codul si nu aduce nimic folositor.
 

h2. Un plan de atac
Unele probleme din infoarena2 nu origineaza neaparat in cod, dar in modul nostru de lucru. Aici am pus niste idei pentru a imbunatati procesul de dezvoltari. Teoretic ar putea fi aplicate si in infoarena2.