Tietokantaa suunniteltiin projektin aikana todella tiiviisti ja kauaskantoisesti. Tietenkään kaikkia seikkoja ei voitu ennakoida, ja joten kesän aikana tarvittiin joitakin lisäyksiä olemassa oleviin tauluihin ja uusia taulujakin jouduttiin luomaan. Tietokanta lienee kuitenkin onnistunein osa Kottarainen-projektin perintöä. Perusrakenne toimi mainiosti luodun oliorakenteen kanssa ja laajeni kivuttomasti jatkokehityksen tarpeisiin. Tietokantasuunnittelun onnistumiseen vaikutti varmasti eritoten projektiryhmän erään jäsenen aikaisempi kokemus vastaavasta suunnittelusta sekä suunnitteluvaiheen tiivis yhteistyö tietokannoista hyvin perillä olevan Korppi-tiimin kanssa.
Tietokannassa erityisen hyvältä idealta vaikuttaa se, ettei kyselyyn liittyvien metatietojen määrää ole rajoitettu sijoittamalla ne varsinaiseen kyselyn sisältävään tauluun. Metatietojen arvoille on omat taulunsa kutakin rakennekerrosta (kysely, kysymysryhmä, kysymys, vastaus) kohden ja ne liittyvät "omistajaansa" id:n kautta. Kaikki metatietotyypit sijaitsevat kuitenkin samassa arvoista erillisessä taulussa, joten kesän aikana oli välttämätöntä lisätä taulu, joka kertoo, mille rakennekerrokselle mikäkin tyyppi kuuluu (esimerkiksi kysymysryhmä-tasolla ei ole metatietotyyppiä "kyselyn tyyppi"). Näin ollen saadaan kuitenkin joustavuutta siihen, kuinka metatietojen syöttäminen käyttöliittymän tasolla toteutetaan. Hiukan hiomista jatkossa tarvittaneen siihen, mikä syöttökenttä kunkin metatietotyypin yhteyteen tulostetaan, jottei kaikkia tietoja syötetä avoimiin tekstikenttiin. Tämä vaatinee uuden viitetaulun metatietotyypin ja syöttökenttätyypit määrittävän taulun välille.
Oliorakenne, jossa jokainen olioluokka käsittelisi aina yhtä tietokannan taulua tallentaen ja hakien tietonsa tuntematta muita olioita kuin alaisensa, oli sovelluksessa sinänsä mainio idea - teorian tasolla. Jo projektin aikana huomattiin, että oliorakenteen hakeminen tietokannasta kesti aivan liian kauan ja sen tallettaminen samoin. Jokainen olio avasi lisäksi tietokantayhteyden ja kirjoitti log-tiedostoon, mikä entisestäänkin hidasti toimintaa. Kottarainen-sovelluksen tapauksessahan jo yksi kysymysmatriisi, jossa on 5 x 5 radioryhmä, joka sijaitsee kysymysryhmän sisällä kyselyssä tuottaa jopa 32 oliota, joten normaalin kokoinen kysely tuottaa niitä määrättömän määrän. Jatkuva tietokantayhteyksien aukominen ei siis käynyt päinsä.
Ensimmäinen tapa nopeuttaa hakua ja tallennusta oli vähentää tietokantayhteyksien määrää viemällä avattua tietokantayhteyttä ylemmiltä olioilta alemmille parametrinä. Tämä tuotti hiukan tulosta, mutta ei läheskään tarpeeksi. Etenkin vastausten tallentaminen, jossa koko rakenne ensin haettiin kannasta uudestaan ja sitten talletettiin vastaukset oli ehdottomasti liian hidas. Vastausten tallentamiseen kehitettiinkin oma papusensa, joka hoiti vastausten tallentamisen hakien vain questionfield- ja questionresult-olioihin tarvittavat tiedot. Vastausten tallentaminen muuttui siedettävän nopeaksi.
Haku ja jsp-sivun tuottaminen oli edelleen liian hidasta, joten aloitettiin testailu, josta on kerrottu tarkemmin raportissa Kottaraiseen puhtia . Hakuun kehitettiin oliorakenteen ideaa vastaan sotiva järjestelmä, jossa alikyselyillä haettiin kaikki kyselyn tiedot noin kymmenellä haulla ja yksi papu, Htmlquestionnaire, haki ja loi kaikki oliot kerralla. Tämä nopeutti sovelluksen toimintaa huomattavasti, kuten Kottaraiseen puhtia -raportista näkyy.
Tietokantahakujen nopeuttamisen yhteydessä huomattiin alkuperäisen sovelluksen toinen suuri nopeuden pullonkaula: html-koodin muodostaminen, joka Kottarainen-sovelluksen tapauksessa tapahtui templatehandler-käsittelijän avulla. Templatehandlerin toimintaa on kuvattu tarkemmin Kottarainen-projektin tuottamassa Templatehandlerin käyttöohjeessa. Perusidea on kuitenkin se, että kaikki html- ja sql-koodi sijaitsevat erillisessä tekstitiedostossa, jossa muuttuvat arvot ovat makroina, jotka viedään sinne papusten puolelta. Muuttujien arvoilla täydennetty html- tai sql-koodi palautetaan joko jsp-sivulle tai tietokantaan. Hyöty on sikäli suuri, että haluttaessa muuttaa tiettyä html-koodin pätkää, se löytyy nopeasti parista tiedostosta ja esimerkiksi kaikki html-koodi sijaitsee lähekkäin java-koodin häiritsemättä tarkastelua. Samoin sql-lauseet löytyvät kätevästi kutakin papua vastaavasta tekstitiedostosta.
Templatehandlerin sivun muodostuksen nopeuteen vaikuttava seikka oli se, että se loi jokaiselle oliolle uudestaan templatehandler-käsittelijän ja haki jokaisen kutsun tullessa kyseisen tekstitiedoston sisällön uudestaan muistiinsa. Sivujen sisällön kasvaessa haettavaa alkoi olla jo melkoisesti. Tästä selvittiin muuttamalla käsittelijä staattiseksi olioksi ja muuttamalla sen toimintaa siten, että kaikki tiedostot haettiin vain ensimmäisellä kerralla muistiin, jossa ne säilyivät olion elinkaaren ajan. Jos templatehandlerin nopeuteen aluksi aiheuttaneita ongelmia ei oteta huomioon, se on osoittautunut oikein toimivaksi ratkaisuksi, kun sen käyttöön ensin perehtyi kunnolla.
Toinen html-koodin muodostuksen hitauteen ilmeisesti vaikuttanut seikka oli String-muotoisten muuttujien käyttäminen StringBufferin sijaan. StringBuffer-tyyppisten muuttujien tapauksessa tekstin lisääminen alkuperäisen tekstin perään ei ilmeisesti ole niin raskas ja hidas toiminto kuin Stringin tapauksessa. Tästä ei kuitenkaan saatu varmaa testitulosta, sillä tyyppimuutos tehtiin saamaan aikaan templatehandlerin muutosten kanssa.
Alunperin Kottarainen-sovelluksen rakenne toimi Vector-tyyppisen taulukon varassa. Kullakin luokalla oli Vector-taulukko, jossa sen alaiset oliot sijaitsivat. Tämä toimikin niin kauan kuin olioita ei tarvinnut järjestää mitenkään. Jossain vaiheessa kuitenkin havaittiin, että luodun kyselyn ryhmät vaihtoivat paikkaansa eri tietokannan hakukerroilla. Lisäksi tuli eteen muutoinkin kysymysten ja kysymysryhmien järjestyksen vaihtaminen.
Rakenne oli pakko vaihtaa. Itsestään järjestäytyväksi rakenne tyypiksi valittiin TreeMap. Kaikkien olioiden metodien muuttaminen toimimaan Vectorin sijasta TreeMapin kanssa oli hidasta ja työlästä. Tässä vaiheessa päätettiinkin ottaa käyttää uusi papu, SurveyElements, joka nostettiin kaikkien rakenteesta vastaavien papujen yliluokaksi ja johon laitettiin kaikki uusi kaikille yhteinen aines. Yliluokka olisi tietenkin kannattanut pohtia valmiiksi jo projektin aluksi tai edes kesän aluksi, niin vaivaa olisi säästynyt melkoisesti. Myös se, että tarvitsiko rakenteen olioita jossain vaiheessa järjestää jollain tavalla, olisi kannattanut miettiä ennen yhdenkään pavun luomista. Jälkikäteen koko sovelluksen muuttaminen on melkoisen kismittävää touhua.
Projektinaikainen suurin munaus oli perustaa Kottarainen-sovellus liiaksi jsp-sivujen sessio-muuttujan varaan. Erhe tapahtui monen tekijän summana: projektiryhmä ei lukenut tarpeeksi tarkasti Korppicoding-ohjetta, jossa oli lueteltuna Korppikehittäjien huonoja kokemuksia, eikä kukaan ohjaajista tullut kertoneeksi asiasta, kun koodia ei alkuvaiheessa tarkastellut kunnolla kukaan projektiryhmän ulkopuolinen. Tietoa ja kokemusta oli liian vähän.
Korppi-järjestelmään osaksi tulevana sovelluksena Kottarainen ei pystynyt käyttämään alkuperäisen kaltaisia valtavia tietorakenteita sessiomuistissa, joten sovellusta muutettiin niin, että rakenne tallennetaan mahdollisimman usein ja haetaan kannasta tarvittaessa. Tiedot välitetään URL:ssa tai piilokentissä sivuilta toisille siirryttäessä.
Eräs hyvin inhottava ja kauan aikaa vienyt ongelma liittyi selainten puskuriin. Koska oliorakennetta oli session käytön vähentämisen jälkeen tallennettava jatkuvasti, oli linkeistä toisille sivuille siirtyminen tehtävä redirectin kautta tallentamisen jälkeen. Tätä ennen puskuri on kuitenkin huomattava tyhjentää, sillä puskuriin jääneet tiedot särkevät hämäävästi seuraavan sivun html-koodin ja sivu ei tulostu oikein. Jos puskuri on liian pieni, ei sen tyhjentäminenkään auta, vaan puskurin kokoa on kasvatettava. Myös Korpin valikot sisältävä menus.inc-tiedosto tulee sisällyttää jsp-sivulle oikeaan paikkaan eli vasta redirectin sisältävän koodilohkon jälkeen, sillä muutoin puskuri täyttyy liiaksi. Jatkokehitysryhmä ei tietenkään tiennyt puskurin kasvattamisvaatimuksesta tai menus.incin paikasta. Ongelmaan tuhraantui monta päivää ja paljon miestyötunteja ennen kuin jatkokehitysryhmää silloin tällöin konsultoinut Jussi Mäkinen huomasi puskurin koon vaikutuksen ja ryhmä löysi menujen oikean paikan. Sittemmin ohjeet onnistuneen redirectin tekoon ovat ilmaantuneet Korppicoding-ohjeeseenkin...
Vasta projektin jälkeen kävi ilmi, että Kottarainen-projektiryhmälle ei ollut järjestetty perehdytystä Kotka-papuihin. Millainen tämä perehdys olisi ollut, emme voi tietää, mutta ainakaan nyt ei valmiita papuja ja ratkaisuja tullut paljonkaan hyödynnettyä. Projektin aikana teknisenä ohjaajana ja kesällä yksityisenä henkilönä Jussi Mäkisen antamat vinkit joistakin pavuista auttoivat kyllä joissakin tilanteissa. Ryhmä olisi voinut olla myös itse aktiivisempi valmiiden papujen etsiskelyssä. Toisaalta käyttäjäryhmiä ja -oikeuksia sovellukseen liittettäessä jatkokehitysryhmä joutui tutustumaan olemassa oleviin papuihin ja jsp-sivuihin, jolloin kyllä huomatiin selvästi, ettei kommentointi ollut lähelläkään riittävää. Jälkikäteen ajatellen projektin aikana olisi tärkeää kiinnittää huomiota myös koodin laatuun ja kommentointiin. Nyt ryhmä on saanut puuhastella aivan rauhassa omiaan ja keksiä huonoja ratkaisuja, jotka jokin maailmaa nähnyt ulkopuolinen olisi heti havainnut toivottomiksi yrityksiksi. Lisäksi olisi lienee aivan oleellistakin oppia projektin aikana tuottamaan toistenkin ymmärtämää ja helposti uudelleen käytettävää koodia. Korppiin liittyvien koodien kommentoituttaminen ei myöskään olisi ollenkaan huono idea.
Kotka-pavut aiheuttivat hankaluuksiakin kesän aikana. Kottarainen-jatkokehitysryhmä siirtyi CVS-versionhallinnassa Korppikehittäjien kanssa samaan versionhallinta haaraan heti alkukesästä ja ongelmia alkoi tulla. Pääsääntöisesti versionhallinnassa lienee tarkoitus ottaa aina uusimmat versiot ennen kuin töitä aamulla aloittelee, jotta koodirivit eivät mene sotkuun useamman ihmisen muutellessa tiedostoja. Korppikehittäjillä tuntuu kuitenkin välillä olevan huolimattomuutta tiedostojen CVS:ään laittamisessa: osa muutoksista unohdetiin päivittää versionhallintaan, jolloin jos joku onneton meni ottamaan päivitetyt versiot tiedostoista ja sai jonkun muokatun tiedoston, pavut eivät hänellä enää kääntyneet toisen tiedoston puuttuvien osien vuoksi. Tämä esti usein Kottarainen-sovelluksenkin toiminnan. "Pienet" jatkokehittäjät eivät aina uskaltaneet hiillostaa "isoja" Korppitiimiläisiä toimimattomista pavuista, joten kun ryhmä oli muutaman kerran monta tuntia uurastanut toimimattomien papujen vuoksi, se päätyikin olemaan useimmiten ottamatta uusimpia versioita muista kuin omista päähaaran pavuista.
Projektin ajalta jäi kesän jatkokehitykseen kaipaamaan palavereja. Niitä ei olisi tarvinnut niin usein kuin projektin aikana, mutta muutama kesän aikana olisi ollut tarpeen, jotta tilaajaosapuoli olisi pysynyt selvillä siitä, miten työ edistyy. Lisäksi olisi ollut tarpeen saada aikaisemmassa vaiheessa enemmän palautetta sovelluksen ulkoasusta. Nyt palaute jäi hiukan yksipuolisesti parin testaajan ja ryhmän omien kokeilujen harteille. Nykyisellään Kottarainen ei ole erityisen helppokäyttöinen, vaikka siitä nimenomaan suunniteltiin helppokäyttöistä kyselyidenlaadintasovellusta.
Käyttäjäryhmien hallinnan ja käyttäjäoikeuksien määrittelyn tultua ajankohtaiseksi kesällä, joutui ryhmä päättämään omin nokkinensa monet linjanvedot. Tässä olisi eritoten olleet palaverit poikaa. Ryhmällähän ei ole minkäänlaista käytännönkokemusta siitä, millaisia käyttäjäoikeuksia minkäkinlaisille ryhmille olisi tarpeen olla.
Kun jatkokehitys alkoi, monet ongelmat selvisivät kuin itsestään korppiadmin-sähköpostilistan avulla. Korppikehittäjät vastasivat nopeasti ja avuliaasti pienten jatkokehittäjien kysymyksiin silloin, kun niitä uskallettiin heille esittää (loppukesästä enemmänkin). Heiltä sai korvaamatonta apua moneen ongelmaan. Projektin aikana Korppitiimiä ei oikeastaan kehotettu lähestymään. Toki projektin ongelmat varmasti häiritsisivät paljon "oikeiden työläisten" toimia, mutta olisiko kuitenkin mahdollista saada jotenkin kommunikaatiota pelaamaan Korppiin liittyvien projektien jäsenten ja Korppitiimin välillä?