Jeg tror grunnen til at programmet henger iblant er at det finnes
flere åpne sesjoner, og at en annen sesjon har låst noe den aktive
sesjonen vil bruke.
De fleste menyene som ikke gjorde noen endringer lukket ikke sesjonen
sin, og selv de som gjorde endringer lukket sesjonen bare hvis de ble
fullført, ikke hvis de ble avbrutt.
Jeg har flyttet all åpning og lukking av sesjoner til funksjonen
Menu.execute, og lagt til egenskapen Menu.uses_db. For menyer som har
denne egenskapen satt til True lages det en sesjon i begynnelsen av
execute, og den lukkes før execute returnerer (lukkingen er beskyttet
av en finally).
Tips for debugging av denne typen problemer (dersom de vedvarer):
SELECT * FROM pg_stat_activity;
SELECT * FROM pg_locks;
Brukergrensesnittet er forsøkt forbedret. Forandringene er basert på
observasjoner av reelle brukeres handlinger.
* Buy-menyen har fått litt ekstra magi for tilfellet der inputstrengen
ikke gir noe treff i databasen. Hvis strengen ser ut som et
brukernavn (dvs finnes i /etc/passwd) eller kortnummer får man
spørsmål om man vil lage brukeren. For kortnummer får man også
muligheten til å assosiere kortnummeret med en eksisterende bruker.
* AddUserMenu presiserer litt tydeligere hva det forventes at man skal
skrive: at brukernavnet skal være PVV-brukernavn og at kortnummeret
kan utelates.
* Menu.confirm er gjort case-insensitiv, så den godtar strengene 'y',
'n', 'yes', 'no' i alle kombinasjoner av små og store bokstaver.
Har nå mulighet for default-valg i confirm (default-en vises med stor
bokstav, som i '(Y/n)', og velges hvis man skriver en tom linje), og
confirm leser input på samme måte som alt annet (via Menu.input_str).
Har laget en funksjon safe_str som prøver å gjøre om et vilkårlig
objekt til noe Python kan printe uten å bli sur. Tok i bruk denne i
raw_input-kallet i Menu.input_str (det viser seg at raw_input blir
muggen hvis den får et unicode-objekt som inneholder ikke-ASCII-tegn).
Uten dette risikerer man å se informasjon fra forrige gang menyen var
åpen når man sier 'what'. BuyMenu var rammet av dette problemet;
kanskje andre menyer også.
* Ny tabell Transaction som brukes for alle transaksjoner; hver
transaksjon kan være knyttet til en Purchase eller ha en tekstlig
beskrivelse. (BuyMenu og TransferMenu viser de to måtene å bruke
Transaction på)
* Hvert kjøp kan ha flere brukere. Prisen fordeles likt blant
kjøperne (for øyeblikket antar jeg at alle pengebeløp i databasen er
lagret i kroner, og når totalprisen for et kjøp ikke går opp i
antall kjøpere rundes det ned til et helt antall kroner)
* Forbedret input i BuyMenu -- den gjetter på om man skriver inn et
produkt eller en bruker basert på hvor den finner treff. (Hvis
treffene er like gode begge steder velges det vilkårlig -- dette kan
endres om det viser seg å være et problem i praksis)
* BuyMenu lagrer faktisk kjøpene i databasen.
* ShowUserMenu viser alle transaksjonene til brukeren. Dette kan bli
mye etter hvert, så det bør sikkert begrenses på et eller annet vis
(for eksempel at den bare viser de siste N, for et egnet naturlig
tall N).
* Menu-klassen utvidet med kode for å vise menyen og velge ting fra
den, samt litt mer generelle funksjoner for å lese input
* Ny klasse Selector for «små» menyer som bare er for å velge en verdi
(disse skal ikke ha undermenyer)
* Nye menyer: ShowUserMenu, BuyMenu (foreløpig med kun innlesing av
data, ikke lagring), ProductListMenu
* Forsøk på «intelligent» håndtering av input i BuyMenu (se
funksjonene dwim_search og guess_data_type)
* La inn to tøyseprodukter i datafilen for å ha noen produkter å teste
med
