This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-08
Channels
- # announcements (32)
- # aws (2)
- # babashka (21)
- # beginners (143)
- # cider (3)
- # cljsrn (13)
- # clojure (65)
- # clojure-dev (7)
- # clojure-europe (20)
- # clojure-losangeles (8)
- # clojure-nl (13)
- # clojure-norway (39)
- # clojure-uk (9)
- # clojurescript (39)
- # code-reviews (10)
- # conjure (2)
- # cursive (3)
- # datascript (6)
- # datomic (40)
- # events (5)
- # exercism (23)
- # fulcro (9)
- # funcool (2)
- # girouette (2)
- # graphql (4)
- # helix (8)
- # improve-getting-started (4)
- # integrant (7)
- # introduce-yourself (5)
- # jobs (3)
- # luminus (32)
- # malli (3)
- # off-topic (10)
- # pathom (9)
- # pedestal (4)
- # polylith (25)
- # practicalli (1)
- # re-frame (4)
- # sci (3)
- # shadow-cljs (5)
- # tools-deps (25)
- # vim (31)
- # xtdb (32)
Det gledes til dagens clojurelønsj. Er det noen lokale som har anbefalinger til gode steder å skaffe mat til gildet?
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.
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?
Det eg ynskjer å løyse er å unngå at ein http request som feiler også tar med seg "hovedtransaksjonen"
Ja. Nokre hovedtransaksjoner inkluderer data frå http, dei fleste ikkje
Per no er det slik at hovedtransaksjonen feiler fordi http requesten gir exception.
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
Ja (avhengig av Datomic (squuid) som er ny primærnøkkel for hovedtransaksjonen)
Du kan ha en timeout på http requestene. F.eks. gi de 2s på å fullføre, hvis ikke, gjennomfør hovedtransaksjonen uansett
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)
Har sett (og ser) på den ja
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?
Bruker clj-http
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 ...
Hva med å lage gi hovedtransaksjonen en attribut som sier om http-kallet er utført eller ikke?
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"
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
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)
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å).
Hva er det du har gjort? En slags loop som ser gjennom databasen etter transaksjoner som trenger et http-kall?
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