Hente alle reviews via API

[boutros]

Feks ved get http://data.deichman.no/api/reviews offset=0 limit=1000 order-by=date får man de første 1000 Da kan vi cache hele sulamitten hver natt f.eks

Kan jo også gjøre dette via adapteret, men hvis det er enkelt å ordne i API så er det enklere - da får vi det i riktig format.

[bensinober]

skal fikse. order-by bør kanskje være created? (vs issued og modified)

[asgeirr]

Synes issued virker riktigere. Ellers kan en nypublisert anbefaling havne langt bak, hvis kladden ble opprettet for en stund siden.

[bensinober]

lagt til nå. valgfritt order_by. order=asc/desc rspec feiler konstant. har gitt opp. får ikke gjenbrukt variabelen @uri fra opprettet anmeldelse i test

[boutros]

Har ikke brukt rspec no særlig, men tror det vil være letter å debugge hvis du setter opp testdata for hver test for seg. Sitat noe jeg fant i docs:

WARNING ABOUT before(:all) and after(:all)

It is very tempting to use before(:all) and after(:all) for situations in which it
is not appropriate. before(:all) shares some (not all) state across multiple examples. This means
that the examples become bound together, which is an absolute no-no in testing. You 
should really only ever use before(:all) to set up things that are global collaborators
but not the things that you are describing in the examples.

[boutros]

Tror heller ikke det er meningen å ha tester i selve before og after blokkene

[boutros]

Skal reviews grupperes under works, når det er snakk om en liste over siste anbefalinger? Synes det ville være naturlig med kun en anmeldelse per works i den lista.

Eller så synes det er bra at responsformatet er det samme overalt, det gjør det letter å parse:)

Ang "reviewer": "[S.n.]", hvem er [S.n] - ukjent anmelder?

offset, limit, order by og order funker strålende :-)

[boutros]

For å presisere, slik er formatet jeg kunne tenke meg på dette: En array av hash - der hver hash har nøyaktig samme format som jeg ville fått ved å spørre api via URI til anbefalingen.

altså {works => [blblba, reviews => [blbla]]}

Dette for å gjøre det veldig enkelt å cache.

Gir det mening?

[asgeirr]

[S.n.] er katalogsjargong. 'Sine nomine' - uten navn. For å redusere antall optionals i spørringene har vi lagt på noen dummy-verdier på anbefalingene i de gamle datasettene, blant annet reviewer. Alle nye anbefalinger vil ha reviewer, og det er dumt å forsinke spørringene for å ta høyde for at anbefalingene fra Ønskebok ikke har det.

[bensinober]

Det er nettopp dette jeg ikke skjønner. Hvorfor skal jeg teste noe jeg vet funker? Hele poenget med å teste live POST via APIet er at jeg IKKE har kontroll på resultatet (=unik URI) og derfor må bruke resultatverdier videre i testene.

This means that the examples become bound together, which is an absolute no-no in testing.

Dette lyder søkt i mine ører. Hvis dette skal fungere må jeg lage et mockresponse for alle testene. Jeezas! Legger testingen død for nå. Har kastet bort for mye tid.

Benjamin

2013/1/24 Petter Goksøyr Åsen notifications@github.com

Har ikke brukt rspec no særlig, men tror det vil være letter å debugge hvis du setter opp testdata for hver test for seg. Sitat noe jeg fant i docs:

WARNING ABOUT before(:all) and after(:all)

It is very tempting to use before(:all) and after(:all) for situations in which it is not appropriate. before(:all) shares some (not all) state across multiple examples. This means that the examples become bound together, which is an absolute no-no in testing. You should really only ever use before(:all) to set up things that are global collaborators but not the things that you are describing in the examples.

— Reply to this email directly or view it on GitHubhttps://github.com/digibib/data.deichman.api/issues/4#issuecomment-12635836.

[boutros]

Ah, ser poenget. Ikke meningen å mase altså

[bensinober]

ang: En array av hash - der hver hash har nøyaktig samme format som jeg ville fått ved å spørre api via URI til anbefalingen.

altså {works => [blblba, reviews => [blbla]]}

det er enklere å returnere hvert resultat som du skriver over, altså en verk-hash per anmeldelse. Da slipper jeg å clustre verk i APIet. Grunnen til at jeg gjorde det var for å gjøre det mer presenterbart og for at klienten skal slippe å clustre anmeldelser av samme verk. Skal jeg fjerne clustringen (enklest), eller skal vi gjøre det valgfritt, f.eks. med et parameter i apiet? cluster=true/false eller no?

ang tester: det er ikke du som maser ;) jeg ville bare være være flink og skrive tester, og så funker det ikke. selvfølgelig skjønner jeg at det er funksjonaliteten, ikke resultatet som skal testes, men læll...

[boutros]

Clustring per verk gir mening når man søker etter forfater og tittel, men når man bare skal ha en liste over de siste anbefalingene, så er det vel mer med riktig slik som jeg beskriver? Skjønner heller ikke hvordan man kan clustre reviews per verk når det skal sorteres etter review.issued forrøvrig

Så sånn for applikasjonen sin del, så vil det ikke være nødvendig med clustring der. Men hvis du ser for deg annen bruk så er det jo helt i orden med et cluster-parameter.

Har forøvrig 0 tester selv foreløbig :-/

[bensinober]

APIet tar nå imot array av urier. Etter å ha gravd lenge i RDF::Query::Solutions fant jeg at en faktisk kan endre solutions-arrayet, så lenge en holder seg til Solution-objekter. Disse har metoder for bl.a. 'merge' som gjør det mulig å slå sammen resultater. Kan bli nyttig senere.

Test gjerne mest mulig, for jeg tenker å sette det i drift på data.deichman.no en av de nærmeste dagene.

[boutros]

Funker bra det! Testet med 1, 2, og 3 urier, både riktige og tulleurier.

Ah, har slitt selv med å forstå hvordan egentlig bør jobbe med query::solutions,

[boutros]

Hei, går det an å skru av clustringen også når jeg spør på reviewer?

http get datatest.deichman.no/api/reviews reviewer=petterrrrr cluster=false

[bensinober]

Gjort. Clustring var egentlig klart allerede, men nå er det valgfritt parameter.

jeg får dog bare boolean-parameter til å funke med json: http get datatest.deichman.no/api/reviews reviewer=petterrrrr cluster:=false

cluster=false sender som tekststreng "false" Benjamin

2013/2/19 Petter Goksøyr Åsen notifications@github.com

Hei, går det an å skru av clustringen også når jeg spør på reviewer?

http get datatest.deichman.no/api/reviews reviewer=petterrrrr cluster=false

— Reply to this email directly or view it on GitHubhttps://github.com/digibib/data.deichman.api/issues/4#issuecomment-13759126.

[boutros]

Supert:)