Foto: Enångers Hembygdsförening
Att skörda från Sockenbilder var lite småklurigt då lokalnoden i K-samsök inte är byggd för att skörda den typen av system. Sockenbilder lagrar sin data i XML-filer och har en XML fil för varje hembygdsförening. För att överhuvud taget kunna skörda så bad vi Jan-Åke Malmkvist att slänga ihop en XML-fil där han för varje socken anger URL:en till varje XML-fil och sökvägen till vart bilderna ligger för varje hembygdsförening då detta inte anges i datat i XML-filerna.
För att göra det möjligt att skörda sockenbilder behövdes i stort 3 klasser. En adapter, som är den klass som står för mappningen av data och också är den klass som lokalnoden kommunicerar med när den vill ha data från Sockenbilder. Adaptern använder i sin tur sig av en sökklass för att hämta själva datan från Sockenbilder. Sen finns det i sin tur en böna som är byggd för att hålla den data som hämtas från sockenbilder.
När En skörd initieras så vill lokalnoden ha ett värde på antalet poster som finns att hämta. Eftersom det inte finns någon siffra på detta hos Sockenbilder som jag kommer åt lätt så löste jag detta genom att den vid första anropet läser in XML-filen med alla URL:er till Sockenbilders XML-filer med data. Därefter hämtar den i tur och ordning dessa XML-filer och låter en SAX parser tugga i sig dessa och räkna ihop hur många poster det finns totalt.
Nästa sak som måste fixas direkt i första anropet är att meddela hur många poster den får. Detta var den riktigt kluriga delen. I vanliga fall kan man ha ett fast värde på denna. Alltså att den exempelvis hämtar 500 poster åt gången. Men eftersom datat för Sockenbilder ligger i flera XML-filer så var tanken att hämta data från en fil i taget. Jag gjorde så att adaptern direkt i konstruktorn med hjälp av en metod i sökklassen hämtar en siffra på hur många poster nästa fil innehåller, alltså detta måste den kolla varje gång då varje ”batch” är olika stor. Detta tycktes till en början fungera mycket bra. Men som Murphys lag säger: ”If anything can go wrong, it will” och det var precis vad det gjorde! Vissa av de XML-filer som hämtades innehåller relativt stora mängder data. När denna klump med data kom till centralnoden så tyckte centralnoden att den hade för lite minne för att hantera den mängden data. Personligen tyckte jag att centralnoden var lite gnällig och borde skärpa till sig, men centralnoden var tydligen rätt bestämd på den punkten…
Så inte nog med att jag måste skörda från flera URL:er, vilket systemet inte är byggt för, jag måste även dela upp datamängder som inte har någon som helst möjlighet att läsa lite, skicka det, läsa lite till osv. Jag och Börje (Lewin) beslutade att vi kunde lösa detta genom att temporärt spara data som hämtades om det var så att den innehåll stora datamängder. Alltså om en XML-fil som hämtas från Sockenbilder innehåll fler än 1000 poster så skickar vi endast tillbaka 1000 poster. Resten sparar vi ner till en temp fil. När sen nästa bunt skall hämtas så kollar sök klassen först om det finns en temp-fil som innehåller sparat data. Om det gör detta så skiter den i att hämta data från nästa URL och läser istället in filen och tar 1000 nya poster från denna, om det finns 1000 det vill säga, annars tar den alla som återstår. Efter lite pill och fix så lyckades jag dock få denna metod att funka mycket bra dock.
Ett annat trevligt problem jag hade var att jag på något sätt måste veta vilken URL till sockenbilder som skall användas varje gång. Eftersom jag läser in resurs filen med URL:er till Sockenbilder i en bestämd ordning och lagrar dessa i en lista så tyckte jag att det borde funka att ha ett index som pekar på vilken som skall skördas och fixa så att detta index behåller sitt värde mellan sessioner. Detta är sån tur är inte ett stort problem i Java, vilket inte gjorde det till ett stort problem. Dock fick jag till en början en liten bugg som gjorde så att om en skörd av någon anledning avbröts så började skörden på fel ställe nästa gång. Detta löste jag dock genom att nollställa denna räknare om “offset“ var 0, vilket det endast är första gången.
Detta sammanfattar nog de relevanta problem jag hade vid implementerandet av detta. Låter inte så krångligt nu när jag skriver det men hjärnan jobbade på högvarv ett antal timmar för att lösa vissa av dessa problem.
Läs mer om Sockenbilder i K-blogg.
>> Henrik Hjalmarsson är systemutvecklare på Riksantikvarieämbetet och jobbar med K-samsök.