Fork me on GitHub
#clojure-norway
<
2021-09-08
>
msolli06:09:34

Det gledes til dagens clojurelønsj. Er det noen lokale som har anbefalinger til gode steder å skaffe mat til gildet?

mariuene06:09:55

Det er en mathall i kjelleren til sten og strøm, masse bra der

slipset07:09:26

Knerten & Camên i Rådhusgata 20 er ikke så ille. Enklere enn Stæl og Røm

😹 2
msolli07:09:12

Takk for tips!

Ivar Refsdal09:09:31

Eg spurte om eit spørsmål på Datomic-kanalen: Nokon her som har ei meining om følgande? I have a Datomic backend application that primarily writes and reads from the database. Sometimes however it needs to talk to external HTTP services and put response values from those into the database. These values are currently added as a part of a larger transaction. Sometimes those HTTP requests fail, and then the whole transaction fails. What is a good strategy to solve this? I'm thinking of adding a queue job in the database to make HTTP requests in order to accomplish something like https://microservices.io/patterns/data/transactional-outbox.html Is there a library for using Datomic as a queue consumer? Thanks.

Fredrik11:09:02

Hva er det du ønsker å løse? Er det hvordan sende ut mange HTTP requests (en queue kan funke bra til det), eller hva du skal gjøre når en request failer og transaksjonen avbrytes/omstartes?

Ivar Refsdal11:09:55

Det eg ynskjer å løyse er å unngå at ein http request som feiler også tar med seg "hovedtransaksjonen"

Fredrik11:09:47

Så du har en hovedtransaksjon, som kan inkludere data hentet via en http request?

Fredrik11:09:10

Og du ønsker at hovedtransaksjonen gjennomføres selv om http requesten failer?

Ivar Refsdal11:09:39

Ja. Nokre hovedtransaksjoner inkluderer data frå http, dei fleste ikkje

Fredrik11:09:56

Skjønner. Og hvorfar failer hovedtransaksjonen når http requesten failer?

Ivar Refsdal11:09:45

Per no er det slik at hovedtransaksjonen feiler fordi http requesten gir exception.

Ivar Refsdal11:09:13

Spørsmålet er korleis ein løyser dette på ein robust måte der hovedtransaksjonen ikkje må vente på ein http request som potensielt kan feile mange gonger

Fredrik11:09:40

Er http requestene avhengig av transaksjonsdataene?

Ivar Refsdal11:09:44

Ja (avhengig av Datomic (squuid) som er ny primærnøkkel for hovedtransaksjonen)

Fredrik11:09:30

Du kan ha en timeout på http requestene. F.eks. gi de 2s på å fullføre, hvis ikke, gjennomfør hovedtransaksjonen uansett

Fredrik11:09:56

Er det en slik løsning i nærheten av det du tenker på?

Ivar Refsdal11:09:55

Nei, det eg tenkte meir på var å, som ein del av hovedtransaksjonen, lagre ein jobb som skal utførast på eit seinare tidspunkt (http kall i dette tilfellet). Altså ein kø i Datomic. Men eg finn ingen købibliotek for datomic, og lurte på om andre har løyst dette (på denne eller andre måtar)

Fredrik11:09:33

Har du sett på txReportQueue?

Ivar Refsdal11:09:39

Har sett (og ser) på den ja

Fredrik11:09:32

Den ser lovende ut, i mine øyne, til å løse problemet ditt

Ivar Refsdal11:09:59

Den kan nok brukast til å løyse ein del av problemet, men ikkje re-tries f.eks. Kva skal skje etter restart av applikasjonen dersom det "henger" eit feila http-kall?

Fredrik11:09:27

Hva slags bibliotek bruker du till å gjøre http-kall?

Fredrik11:09:04

Dette virker som et separat problem

Ivar Refsdal11:09:15

Bruker clj-http

Fredrik12:09:09

Da kan du sette hvor mange retries du ønsker

Fredrik12:09:46

Og sette en timeout

Ivar Refsdal12:09:33

Ja, det veit eg.. Men problemet er: kva skjer dersom applikasjonen restarter og den ikkje har utført http-kalla som skal gjerast? Då må ein på eit eller anna vis i så fall gjenskape txReportQueue dataa og trigge http-kall på nytt. Ikkje heilt trivielt kanskje ...

Fredrik12:09:57

Hva med å lage gi hovedtransaksjonen en attribut som sier om http-kallet er utført eller ikke?

Fredrik12:09:50

Så kan du ha en egen queue som scanner etter transaksjoner det denne attributen er satt til "false", gjennomfører http-kall, og switcher til "true"

augustl12:09:52

i dynamodb-land (hvor en transaksjon bare kan touche 25 items) ville jeg laget meg en UUID for operasjonen, skrevet ting til databasen ettersom det kom inn, og når alt var ferdig, opprettet noe i databasen som peker på den UUID-en og er hovedpunktet for spørringer for å hente ut slike data. Da blir det potensielt liggende litt støy, men det gjør ingenting siden ingen peker på de

2
augustl12:09:06

(ikke bare ville jeg gjort det sånn, jeg har gjort det sånn)

augustl12:09:39

ble det bra lunsj i dag? 🙂 Hadde store planer om å bli med, men endte opp med å bære flyttelass (mitt eget) i stedet for (ting går fort når man leier i stedet for å kjøpe)

💯 2
Ivar Refsdal12:09:07

Re FVR: Har gjort det slik ein plass i koden iallefall. Ulempa er at det ikkje er spesielt generisk og ei heller (i mitt tilfelle) agerer spesielt raskt. Men ja det løyser problemet (om enn ikkje kjempeelegant, synest eg då).

Fredrik13:09:43

Hva er det du har gjort? En slags loop som ser gjennom databasen etter transaksjoner som trenger et http-kall?

Ivar Refsdal14:09:21

Ja, eller ein attributt. Dette køyrer kvart 5 minutt.

(doseq [id (d/q '[:find [?id ...]
                    :in $
                    :where
                    [?e :x/id ?id]
                    [(missing? $ ?e :x/...)]]
                  db)]
Forsøker meg på eit meir generelt bibliotek no

Fredrik14:09:38

Er attributten på individuelle datomer, eller på transaksjons-datomet?

Fredrik14:09:24

En måte å få mer responsivitet er å kjøre data fra (d/tx-report-queue connection) over på en async channel, og behandle det videre derfra