Aiemmin ilmestyneitä junia poistettu ilman muutoksia

[Ilkka Kudjoi]

Moi,

Meidän talteen ottamien tietojen mukaan mm. nämä junat on joskus ollut saatavilla trains-apista (alla lähtöpäivä/numero sekä API versionumero). Näiden poistoa tai peruuttamista emme kuitenkaan ole vastaanottaneet myöhemmin, kun kyselen rajapinnasta poimittujen junien tietoja vastauksena on tyhjää (eli juna poistettu taustajärjestelmästä).

Pystyttekö selvittämään, miksi tieto poistosta ei ole tullut versioparameterilla kysellessä ulos?

Terveisin Ilkka Kudjoi

2025-01-26/1220 289054939042
2025-01-26/1221 289054939042
2025-01-26/153 289428843131
2025-01-26/162 289054939042
2025-01-26/403 289428843131
2025-01-26/404 289428843131
2025-01-26/407 289428843131
2025-01-26/408 289428843131
2025-01-26/414 289428843131
2025-01-26/417 289054939042
2025-01-26/488 289054939042
2025-01-26/930 289428843131
2025-01-26/946 289054939042
2025-01-26/947 289054939042
2025-01-26/949 289054939042
2025-01-26/950 289428843131
2025-01-26/953 289054939042
2025-01-26/965 289054939042

[rata.digitraffic.fi]

Moro,

/trains rajapinta palauttaa maksimissaan 2500 riviä annetusta versiosta eteenpäin. Dokumentaatiota tämän osalta on nyt hieman parannettu: https://www.digitraffic.fi/rautatieliikenne/#kaikkien-junien-tiedot

Tarkastellaan tuota ensiksi antamaasi esimerkkiä: 2025-01-26/1220 289054939042. Jos tämän tiedot suoraan syöttää /trains APIin, ei sieltä tosiaan löydy uusia päivityksiä junalle 1220. Tämä johtuu tuosta 2500 rivin rajoitteesta.

curl --compressed -H 'Accept: application/json' 'https://rata.digitraffic.fi/api/v1/trains?version=289054939042' | jq 'map(select(.trainNumber == 1220))'

=> []

Jos kumminkin kyselee hieman isommalla versionumerolla, tulee vastauksen mukana oikea rivi.

curl --compressed -H 'Accept: application/json' 'https://rata.digitraffic.fi/api/v1/trains?version=289643614203' | jq 'map(select(.trainNumber == 1220))'

=> [

    {

        "trainNumber": 1220,
        "departureDate": "2025-01-26",

        ...

    }

]

Tietyn junan ja päivämäärän mukaisia tietoja on myös mahdollista hakea /api/v1/trains/{departure_date}/{train_number} rajapinnan kautta

curl --compressed -H 'Accept: application/json' 'https://rata.digitraffic.fi/api/v1/trains/2025-01-26/1220?include_deleted=true'

=> [

    {

        "trainNumber": 1220,
        "departureDate": "2025-01-26",

        ...

    }

]

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

[Ilkka Kudjoi]

Moi,

Nämä versio-rajapinnan rajoitteet olivat tiedossa. Yritin kertoa, että
vaikka jatkuvasti pollaamme train-apia versionumerolla, käyttäen
uudessa kutsussa suurinta edellisen vastauksessa saatua versiota, emme
koskaan ole vastaanottaneet tietoa noiden junien poistosta. Onko ne
siis voineet jäädä välistä?

Terveisin
Ilkka Kudjoi

> --
> Sait tämän viestin, koska olet tilannut seuraavan Google-ryhmän: rata.digitraffic.fi.
> Jos haluat perua tämän ryhmän tilauksen ja sen sähköpostiviestien vastaanottamisen, lähetä sähköpostia osoitteeseen rata_digitraffi...@googlegroups.com.
> Voit katsoa keskustelun osoitteessa https://groups.google.com/d/msgid/rata_digitraffic_fi/10d8df27-12d5-4b3c-962e-51d2f5fddddcn%40googlegroups.com.

[Ilkka Kudjoi]

Hei,

Löysin ehkä ongelman meidän datan vemputusprosessista, keskeyttäkää
selvitykset teidän päässä toistaiseksi.

- Ilkka

[Ilkka Kudjoi]

Moi,

Otankin komentoa takaisin, sekoilin saman numeron eri lähtöpäivien
kanssa. Taidan ehkä kuitenkin ymmärtää ongelman, mutta pyytäisin
vahvistusta. Tässä tilastot esimerkkijunan poistoajankohdalta
kerätyistä junamääristä. Esimerkistäsi selvisi, että poiston olisi
pitänyt olla versiossa 289643614204.

TS _MIN _MAX COUNT(*) 289643614204 BETWEEN _MIN AND _MAX
2024-10-31 06:56:44.000 +0200 289643592301 289643593002 16 false
2024-10-31 06:58:46.000 +0200 289643593003 289643614204 2500 true
2024-10-31 07:00:47.000 +0200 289643616459 289643635215 1366 false
2024-10-31 07:02:44.000 +0200 289643635815 289643635815 10 false
2024-10-31 07:04:46.000 +0200 289643635816 289643657500 2500 false
2024-10-31 07:06:46.000 +0200 289643657770 289643678794 1912 false

Tuosta ilmeisesti voi päätellä, että muutos ei ole mahtunut
kakkosrivin pyynnön vastaukseen, mutta siinä oli mukana samaa
versionumeroa toisen junan tunnisteena. Meille kerätyssä datassa
versiossa 289643614204 on vain junan 2025-01-26/2 päivitys.
Onko siis tämä oikea toimintapa haettaessa jatkuvasti uusimpia
muutoksia: Mikäli vastauksessa on 2500 muutosta, tulee seuraavassa
kyselyssä käyttää esim. versiota "max(edellinen batch) - 1", jotta
tulee varmasti haettua kaikki muutokset, joilla on sama versionumero?
Mikäli vastauksessa on alle 2500 riviä voidaan olettaa, että
vastauksessa ollut suurin versionumero on "immutable" eikä sitä
tarvitse noutaa uudelleen.

Näin toimien tulee haettua joitakin junia turhaan monta kertaa, mutta
onko tähän muuta ratkaisua?
Näemmä suurin määrä muutoksia per versio, mitä olemme koskaan
vastaanottaneet, on 2362. Onhan se toki selvästi alle 2500, onhan
tässä lupaus siitä, että koskaan ei ole enempää per versio?

Terveisin Ilkka

[Teemu Sirkiä]

Moi!

Julian ylläpitäjän näkökulmasta voin todeta, että itsekin pollaan aikataulutietoja versionumerolla, enkä ole huomannut, että mitään tietoa olisi jäänyt tulematta. Suurin määrä junia tulee vähän keskiyön jälkeen, jolloin raidetiedot päivittyvät junille, joiden lähtövuorokauteen on kymmenen päivää. Näitä on esim. viime yönä tullut n. 1800 kpl.

Tuollaista max(version) - 1 menettelyä en ole käyttänyt, vaan versionumeroksi menee aina vastauksessa ollut suurin arvo.

Digitrafficin historiapalvelua (https://rata.digitraffic.fi/history/) hyödyntämällä selviää, että tuo mainitsemasi juna 1220 - esimerkiksi - on peruttu tällaisella aikaleimalla ja versionumerolla:

31.10.2024 08:58:46 (289643614204)

 -Teemu

[Teemu Sirkiä]

Moi!

Vaihdan hattua. Lähdejärjestelmän sovelluspäällikön roolissa aloin vielä ihmetellä, miksi tuohon aikaan on tullut noin paljon muuttuneita junia. Näyttää liittyvän siihen, että säännöllisen liikenteen muutosajankohdan jakopäätös on julkaistu tuolloin aamulla 31.10. klo 8 jälkeen. Tuossa aikataulukauden ensimmäisessä jakopäätöksessä on tullut muutoksia säännöllisen liikenteen juniin koko aikataulukaudelle.

Sinulla on pollausvälinä ilmeisesti kaksi minuuttia. Lähdejärjestelmässä taitaa tapahtua niin, että saman lähtöpäivän junat saavat tuossa junien päivitysprosessissa saman version. Tällöin kahden minuutin aikana on ehditty julkaista useamman päivän junia, jolloin esim. 1800 * 2 on 3600, jolloin tuosta jää 1100 junaa uupumaan 2500 junan rajoituksella.

Juliassa ongelma ei ole tullut vastaan kahdesta syystä: pollaus on tiheämpi (n. 10 sekunnin välein) ja versionumeropollauksella luen vain voimassa olevaa muutoskautta koskevat junat. Jakopäätöksen julkaisun jälkeen lataan seuraavan muutoskauden junat päiväkohtaisesti, jonka jälkeen sallin ko. muutoskauden junien sisäänluvun myös versionumeropollauksen kautta.

Käytännössä tuossa tilanteessa hakemalla juurikin max(version) - 1 saisi aina sen viimeisen version kokonaan (jos oletetaan, että yhdellä versionumerolla ei ole ikinä yli 2500 junaa), jolloin kuitekin jokin määrä junia tulee rajapinnasta tuplana ulos. Tuo määrä asetettiin joskus sen perusteella, paljonko päivässä on junanumeroita käytössä, joten todennäköisesti sen ei pitäisi ylittyä.

Jos haluaisi siis olla ihan täysin varma, ettei missaa mitään, niin tällöin pitäisi varmaankin tehdä siten, että vastauksen koon ollessa 2500 kpl, seuraavalla versionumerohaulla sovelletaan tuota "miinusyksi"-taktiikkaa hyväksymällä se, että osa junista tulee tuolloin uudelleen prosessoitaviksi.

 -Teemu

[Ilkka Kudjoi]

Hei,

Saanko kommentin tähän viimeisinpään viestiini, onko ajatteluni oikeansuuntaista?

Terveisin Ilkka Kudjoi

[Ilkka Kudjoi]

Moi,

Kiitos vastauksistasi Teemu! Kuulostaa siltä, että meille kävi juurikin noin, kuten kuvailit.
Toteutamme siis varmaankin ehdottamani "-1" säännön meidän raaputtelijaan. Esittäisin kuitenkin toiveen rajapinnan kehittämiseksi siten, että tällaista kikkailua ei tarvitsisi tehdä.

Terveisin
Ilkka Kudjoi

[rata.digitraffic.fi]

Hei,

Pahoittelut, että vastauksessa on ollut viivettä. Yhdessä versiossa ei voi olla yli 2500 muutosta.

Alle 2500 muutoksen vastaukset tosiaan sisältävät vastauksessa olevien versioiden kaikki muutokset. Jos vastauksessa on 2500 muutosta, esittämäsi tapa seuraavaksi versionumeroksi query parametrina: "max(edellinen batch) - 1" on oikein. Tuolloin ei jää yhtäkään muutosta saamatta.

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

maanantai 27. tammikuuta 2025 klo 19.44.44 UTC+2 Ilkka Kudjoi kirjoitti:

[rata.digitraffic.fi]

Moro,

Tähän vielä lisäyksenä. Olemme suunnittelemassa toivomasi kaltaista muutosta, mutta toteutuksen aikataulu on vielä avoinna. Tulevaisuudessa rajapinnan vastauksessa on tarkoitus olla pelkästään versioita, joiden kaikki muutokset mahtuvat vastaukseen. Esimerkiksi tuo versio 289643614204 sisältää 95 muutosta. Version kaikki 95 muutosta tulevat jatkossa olemaan vastauksessa, jos ne mahtuvat 2500 rajan sisälle. Jos kaikki 95 muutosta ei mahdu vastaukseen, jätetään se vastauksesta pois. Kyseisen versio tulee sitten kokonaisuudessaan seuraavan kyselyn vastaukseksi, kun query parametri määritetään "max(edellinen batch)". Tästä rajapinnan kehittämisestä myös aiheutuu se, että vastaukset eivät välttämättä sisällä tasan 2500 muutosta vaikka tarjolla olisikin lisää dataa.

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

[rata.digitraffic.fi]

Hei,

rajapintaan on nyt tehty yllä kuvailtu muutos, minkä myötä osittaisia versioita ei enää palauteta, vaan vastaukset sisältävät ainoastaan täydellisiä versioita. Vastauksen koon ylittäessä 2500 riviä jätetään vastauksesta pois järjestyksessä viimeisimmän version rivit. Rajapinnan vastauksen koko on nyt siis 0-2499 riviä.

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

[Ilkka Kudjoi]

Moi,

Entäpä compositions-rajapinta? Törmäsimme eilen ongelmaan, tämä versio palauttaa 1000 tietuetta tismalleen samaa versiota.

https://rata.digitraffic.fi/api/v1/compositions?version=1742307113181

Soveltaen keskustelussa aiemmin mainittua "-1"-sääntöä päädytään ikuiseen looppiin, kun päädymme hakemaan samaa versiota uudestaan ja uudestaan.

Saisko tähän samanlaisen muutoksen, kuin trains-apiin, kiitos!

Terveisin Ilkka Kudjoi

[rata.digitraffic.fi]

Moi,

vaikuttaa tosiaan kaipaavan samanlaista muutosta ja vastauksen koon ylärajan nostoa. Tehdään tästä tiketti toteutusjonoon. Kiitos huomiosta!

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

[Ville H.]

Hei,

Kollegani teki edellisen perusteella samanlaisen muutoksen sekä trains että compositions APIn hakuun. Nyt näyttää, että compositions APIssa, jossa raja onkin 1000 muutosta, on mahdollista tulla yhdessä versiossa yli 1000 muutosta. Ja kun tuo API ei ilmeisesti tue mitään sivutusparametrejä tai limit parametria, niin tuo aiemmin mainittu max-1 ei toimi kun tulee joka kerta samat 1000 muutosta. Ongelmallinen versio 1742307113182 ja ongelma ilmenee kun haetaan urlilla https://rata.digitraffic.fi/api/v1/compositions?version=1742307113181.

Terveisin Ville

[rata.digitraffic.fi]

Hei,

rajapinta on nyt korjattu toimimaan kuten trains-rajapinta sillä poikkeuksella, että mikäli historiallinen versio sisältää yli 1000 kokoonpanoa, niin ne palautetaa kaikki. Jatkossa yhden version maksimi koko on 1000.  

Esimerkiksi https://rata.digitraffic.fi/api/v1/compositions?version=1742307113181 palauttaa nyt kaikki 8192 kokoonpanoa 1742307113182 versiolle. 

Pahoittelumme ongelmasta.

Ystävällisin terveisin / Best regards
– Digitraffic asiakastuki / Digitraffic support –

[Ilkka Kudjoi]

Kiitoksemme!