Návrh nového systému výsledkoviek

[syslo]

Spolu s @black3r sme navrhli nový, všeobecnejší systém, ktorým by sa mohli generovať výsledkovky pre rôzne súťaže.

Pre každú Competition pomocou CompetitionRules (#594) zadefinujeme funkciu calculate_frozen_results, ktorá pre danú sériu a prípadne kategóriu vytvorí frozen results. Počas aktívnej série budú frozen results platné C minút. Pri generovaní výsledkovky sa potom overí, či nejaké frozen results existujú, a ak nie, tak sa zgenerujú. Rovnako sa budú používať frozen results pri akejkoľvek inej potrebe zobraziť body / poradie.

Frozen results budú mať dynamický počet stĺpcov. Vytvorí sa nový model pre frozen stĺpec obsahujúci jeho popis a prípadný foreign key na úlohu. Frozen riadky sa nechajú pôvodné, akurát sa pridá foreign key na predošlé frozen riadky (môže potrebovať seminár pri rátaní bodov a vieme potom vyhoviť prev_rank a prev_points). Frozen bunka bude mať foreign keys na stĺpec a riadok, body za popis a za automatické testovanie, obe nullable, a boolean, či sa ráta do súčtu (#413). Všetky modely okrem frozen stĺpcov momentálne v nejakej podobe existujú.

Funkcii calculate_frozen_results definovanej v defaultných CompetitionRules vytvoríme rozumné helpers ako get_active_submits, customize_columns, customize_row, compare_rows, ... . Jednotlivé súťaže vedia potom preťažiť niektoré helpers ako aj celé calculate_frozen_results.

Ďalšie zmeny:

• body za program sa chcú premenovať na body za automatické testovanie alebo niečo podobné, nakoľko automaticky testovaných interaktívnych úloh pribúda.

Týmto poriešime issues #114 #413 #414 #577

Rád by som názor od @koniiiik a @mhozza.

[mhozza]

• body z testovaca by mohol byt ten nazov
• viac by sa mi pacilo pocas aktivnej vysledkovky generovat dynamicky vysledkovku + ju cacheovat. Vysledkovka by sa pregenerovala vzdy ked sa nieco zmeni a zaroven by sa zakazdym necpali veci do db.
  • Argumenty proti hentomu rieseniu:
  • ako riesitel submitnem program, dostanem body, pozrem vysledkovku, nic sa nezmenilo, som zmateny a smutny, lebo tam tie body nie su.
• mrazenie vysledkovky by som robil az na konci kola, ked budu finalne body (tak ako sa to robi teraz)
• co myslis pod FK na predosle riadky? vsetky riadky ktore su v poradi pred nim? IMHO nepotrebujes, kedze mas frozen vysledkovku, ktora zastresuje vsetky riadky a vies odtial dostat vsetko co potrebujes
• myslim si ze frozen column v principe nie je az tak potrebny
  • v pripade dynamickej vysledkovky sa potrebne info vycuca z pravidiel a ulohy
  • frozen vysledkovka bola myslena ako pomerne hlupy model, ktory proste uchovava data nech su akekolvek, a ani nemusia nutne davat zmysel.

Tot moj nazor.

[black3r]

• FK na predosle riadky sa podla mna mysli FK na riadok s predchadzajucim kolom..
• aj vyberkovy testovac (pouzity napr. na vyberku, celostatku OI, letnej skole, apod.) refreshuje vysledkovku kazdu minutu a nebol s tym doteraz ziadny problem.., pocet bodov za svoj submit vidis vo svojom zozname submitov, kam si redirectnuty po submite
• frozen column chcel byt vytvoreny kvoli tomu, aby mohol mat FK na ulohu, ku ktorej patri, ak patri k ulohe (napr. seriovy bonus nepatri nutne k ulohe, stlpec s bodmi s predosleho kola nepatri ulohe, apod.) a teda aby sme mohli mat vo vysledkovke klikatelny header ktory by riesitela poslal na zadanie ulohy napr.

[mhozza]

Aj tak sa mi nepaci tlacit kazdu minutu novu vysledkovku do databazy. Podla mna cachovanie s cache invalidation po kazdom submite je lepsie riesenie.

[syslo]

• body z testovača znejú fajn
• vytváranie freeznutých výsledkoviek miesto cache bolo navrhnuté z dôvodu jednoduchšej implementácie - nemusíme kódiť transformátor medzi cache dátami a modelmi. Súhlasím však, že cache je čistejšia.
• pod FK na predošlý riadok myslím FK na riadok toho istého usera v predchádzajúcej sérii ako vraví Roman
• každý seminár má inú štruktúru stĺpcov (bonus, total, ...) a mení sa to aj s časom - preto chceme frozen columns.

[mhozza]

• da cachovat cele html a netreba cucat veci z db, co je podla mna nie je ovela efektivnejsie ako pocitat celu vysledkovku zo submitov nanovo). Podla mna to stoji za tu robotu.
• Ad frozen column - aktualne to funguje tak ze ulohove stlpce su dynamicke a zvysne stlpce su priamo v resulte pre uzivatela (suma, predosly pocet bodov...), sem sa podla mna moze pridat aj napr. seriovy bonus a cokolvek bude potrebne. V principe sem vieme dat co treba, ale mas pravdu ze frozen result je flexibilnejsi, co sa tyka zmien v buducnosti (takze kludne go for it).

[black3r]

jeden z reason-ov kvoli comu nestaci cachovat HTML vysledkovky je keby sme niekedy v buducnosti chceli implementovat toto: http://www.kms.sk/mo_races.php?kto=226 (aj ked chapem ze taketo veci sa budu chciet ratat len z freeznutych vysledkov)

dovod preco to davat do DB a nemat python-iu cache bol, aby sme mohli mat jeden sposob tahania aj pre nefreeznute vysledkovky aj pre freeznute vysledkovky (pri tomto navrhu akurat nefreeznute vysledkovky maju platnost 1 minutu a freeznute "nekonecno")

[syslo]

Well, stale vieme mat jeden databazovy format, jeden cache format, jednu rataciu funkciu a jeden interface, ktory vzdy dobre zrobi. Len bude treba konvertery nakodit.

[mhozza]

• tento dovod napadol aj mna, a uznavam ze trochu saje to ze teraz musime mat 2 sposoby (hoci som sa to snazil co najviac prepojit).
• anyway ak to chcete takto, tak ok, ale navrhujem tieto zmeny:
• namiestpo frozenvysledkoviek mat modely pre vyslodkovky (iba premenovat modely, aby to davalo zmysel)
• mat boolean, ktory oznacuje ci je vysledkovka finalna
• nefinalne vysledkovky prepisovat namiesto pridavania (ano, je to trochu zlozitejsie, ale umozni to cloveku sa v tej db potom aj hrabat, namiesto toho aby tam mal miliony vysledkoviek).

[syslo]

Nefinálne výsledkovky vedia tiež byť v nejakej sqlite databáze ktorá bude v RAM. Videl som ako to spraviť, nemám z toho úplne dobrý pocit.

[mhozza]

to myslim ze neni nutne, postgres si to podla mna vie pomerne rozumne zmanazovat.

[syslo]

No a stále tu je problém, na ktorý som zabudol pri spisovani issue ... semináre potrebujú nejaké ďalšie dáta pre každú dvojicu (user, round). Napríklad sú to už spomínané bonus body, nevylučujem však aj ďalšie využitie. Riešenia, ktoré ma napadli:

• ak seminár niečo také potrebuje, vytvorí si vlastný model
• vytvoríme jeden model, ktorý bude uchovávať bonus pointy a budeme dúfať, že nič iné semináre nenapadne.
• vytvoríme model RoundMetadata a necháme každú Competition pchať si tam čo chce, v princípe to bude jediný kód, v ktorom sa to bude využívať.

Nahadzovanie bonusových bodov vie zo začiatku fungovať na defaulnom adminovi (vyplníme počet bodov, user a round -- dostatočne user friendly kým ich je zopár za sériu)

Treba myslieť na to, že tieto veci tiež vedia devalidovať cache výsledkov.

[syslo]

A ešte jedna jednoduchá, ale dôležitá vec, na ktorú som zabudol. Submit chce mať boolean, že sa akceptuje, aj keď je po termíne. Tento boolean bude zaškrtnuteľný jedine vedúcim. Semináre sa občas dohadujú s účastníkmi, že môžu submitnúť o nejaký čas neskôr z nejakého rozumného dôvodu. FKS potrebuje rozlišovať medzi submitom po termíne a ospravedlneným submitom po termíne. A hodí sa to aj na rôzne hotfixy. Vieme to riešiť aj tak, že nastavíme čas submitu na termín odovzdania, z archivačných dôvodov sa mi však viac páči mať na to flag.

[koniiiik]

Nefinálne výsledkovky vedia tiež byť v nejakej sqlite databáze ktorá bude v RAM. Videl som ako to spraviť, nemám z toho úplne dobrý pocit.

Toto už znie na môj vkus hodne prešpekulovane a neviem, či ti to skutočne ušetrí toľko námahy.

Čo sa týka cachovanie vs. prepočítavanie výsledkovky každú minútu, cachovanie je viac “pure,” ale “Practicality beats purity.” Ak prepočítavanie mrazených výsledkoviek znamená menej kódu, som za.

nefinalne vysledkovky prepisovat namiesto pridavania

Toto mi pripadá pomerne samozrejmé – určite nechceme mať pre každú minútu v databáze jednu výsledkovku, na ktorú sa už nikdy viac nič nepozrie.

Ešte by ma zaujímalo, ako presne by malo vyzerať to prepočítavanie mrazenej výsledkovky – na prvý pohľad som si pod tým predstavil kopu insertov, prípadne updatov. To môže byť pomerne drahá operácia, čo by znamenalo, že by sa to asi nemalo diať pri klasickom requeste (a už vôbec by to nemalo byť zakopané kdesi v nejakom template tagu, ako sa nám už v minulosti s niečím stalo). V takom prípade by bolo asi lepšie to spraviť ako nejaký management command púšťaný ako cronjob.

Samozrejme, môžem sa mýliť a ak sa to podarí naimplementovať tak, že to vykoná iba nejakých 10-20 (alebo iné rozumne malé O(1)) databázových query, ktoré zbehnú rozumne rýchlo, tak to asi nebude až taký problém. (Ale stále platí, že to nemá byť pochované v template tagu.)

[mhozza]

Toto mozem zavriet?

[syslo]

@mhozza - Vyriešil som prvú časť v #735, stále však chýba zmrazenie, dokumentácia a testy. Issues o výsledkovke bolo dosť, nechám si teda túto stále otvorenú. Zvyšok si už pozatváral, to je OK.