Fork me on GitHub
#clojure-norway
<
2023-03-31
>
kolstae07:03:59

God morgen!

magnars07:03:19

God morgen! ☀️

magnars07:03:31

@christian767 og jeg skal prøve å finne en dag å få laget flere episoder i påsken. I mellomtiden, her er den siste episoden vi tok opp forrige gang. https://www.zombieclj.no/s02e47.html

🧟 4
😍 4
augustl07:03:13

god morgen! I dag tenker jeg på hvor rart det er at Datomic er så lite utbredt som det er

magnars07:03:37

Ja, du sier noe. Det har jeg tenkt mye på også. I tillegg til Clojure-syken, hvor de største fordelene først blir tydelige etter å ha brukt det lenge, lider vel Datomic også av sin betalingsmodell og lukkede kildekode. Men fy søren for en bra database det er. Jeg prøver å spre ordet i hvert fall. 🙂 https://www.kodemaker.no/blogg/2023-01-datomic/

🎉 4
🚀 4
❤️ 2
slipset08:03:47

Vi valgte ikke Datomic da vi bestemte oss for å gå vekk fra Mongo, fordi vi syntes risikoen var for stor: 1. Vi hadde ingen erfaring med å drifte Datomic 2. Vi fant ingen tilfredsstillende svar på multi tenancy. Vi trenger “god nok” data isolasjon mellom tusenvis av kunder. I dag løser vi det med et skjema pr kunde i postgres og en database pr kunde i Mongo 3. Jeg var redd for at det var viktige datamodelleringsspørsmål som var av typen trap-door som måtte besvares tidlig - før vi hadde fått god nok erfaring med Datomic 4. Vi var på utkikk etter en mindre “åpen” database enn det mongo var, Vi vil altså si at våre data ser akkurat slike ut, dvs statisk typet 5. Jeg er usikker på hva jeg synes om tx-fns. Jeg er veldig glad i sqls deklarative approach for constraings. 6. Det vinnes tusenvis av folk som kan PG, “alle” problemer er løst, mindshare er enorm. Jeg føler ikke det samme kan sies om Datomic

💯 2
slipset08:03:51

Når alt dette er sagt. Skulle jeg startet en sjappe nå, hadde jeg helt klart valgt Datomic.

slipset08:03:54

Jeg sier videre ikke at jeg har rett i alle punktene, men summen av tvil gjorde at vi valgte det trygge framfor det beste.

magnars08:03:59

Nyttig å høre tankene dine om det, @slipset. Jeg ville jo sagt at Datomic oppbygging (basically en decomplected 😅 database) på mange måter gjør den til et tryggere valg, men på en annen akse enn du tenker på her, naturligvis. Liten tvil om at postgres også er et bra valg. Uansett, et par poeng: 1. I motsetning til en database hvor man har en server, så trenger ikke Datomic samme mengde innsats for å drifte. Transactoren har bare én jobb, som den står og gjør uten særlig tilsyn. Query skjer i klientene og rett mot datalageret, så her er det heller ingenting man trenger drifte. 2. Du kan ha så mange databaser du vil mot en Datomic transactor, så en database per kunde for eksempel. 3. - 4. I Datomic beskriver man hvordan dataene ser ut og hvilke typer de har.

Jakub Holý (HolyJak)11:04:13

> 1. Du kan ha så mange databaser du vil mot en Datomic transactor, så en database per kunde for eksempel. Jeg fikk høre senere fra Congitect at On Prem skalerer veldig dårlig med hundrevis av databaser, mens Cloud ville vist klare det. Men vi trengte å kjøre utenfor AWS, og så Cloud sliter med GPRS og man er tilbake i klient-remote server oppsett, som mister en del av run-query-in-app fordeler.

magnars11:04:53

Interessant. Det går kanskje ut over noen optimaliseringer i transactoren.

augustl08:03:16

interessant! Det er jo noe “core” med en database, og skummelt å bruke teknologi som er relativt uprøvd osv. For min del hjalp det veldig at Datomic er såpass simpel i måten den er skrudd sammen, at det på en måte ikke er så mye Datomic kan gjøre for å snuble i sine egne bein. Men likevel…

augustl08:03:39

det skumleste med Datomic sånn sett er om du gjør 2. som Magnar beskriver og har en database per bruker, men plutselig er en bruker stor nok til at du trenger mere enn “et par hundre writes i sekundet” som er Datomic sin maks

augustl08:03:01

angående 5. så er tx-fns en av tingene som etter min erfaring gjør Datomic hyper-digg å jobbe med. Jeg må ærlig innrømme at jeg ikke tør å si at jeg har en komplett forståelse for transaksjonsisolasjon i postgres, når man på uungåelig vis ender opp å gjøre constraint checking i businesslogikken “manuelt” med SQL. Deklarative constraints i SQL funker jo bare til grunnleggende ting som “må være unik”, “må peke på ting som eksisterer” og “kan aldri være null”. At neste versjon av databasen er en funksjon av din egen kode og forrige versjon av databasen, helt uten concurrency og tull, er jo ganske snacks, og gjør det trivielt å modellere domenet mot databasen

augustl08:03:28

men 3. er kanskje det største problemet? Man vet ikke før man er skikkelig godt i gang om man potensielt møter veggen, mens man kan føle seg trygg på at alt av domener lar seg mappe over til postgres siden det er så utstrakt brukt. Jeg hadde samme frykt første gang jeg tok i bruk Datomic husker jeg

augustl08:03:42

svaret på 3 er vel forøvrig at alt som kan modelleres i postgres kan modelleres i datomic, og vel så det? :thinking_face: Man kan vel “emulere” alt en SQL-database kan med datomic + en håndfull tx-functions, om man f.eks vil at det ikke skal kunne eksistere en entitet i databasen med attributt A uten at attributt B også er satt, osv osv

cjohansen08:03:19

Jeg må innrømme at jeg ikke helt skjønner hva som problematiseres i 3. Datomic er en relasjonell database, og som @augustl sier: kan det modelleres i psql så kan det modelleres i datomic. Du har i grunnen enda større frihet siden du kan snakke direkte om enkeltattributter, og ikke trenger å beskrive “tabeller”.

cjohansen08:03:24

4. Datomic er helt statisk typet på attributtnivå, men ikke på entitet-nivå. Databasen lar deg pusle sammen en entitet som du vil. Dette gir deg noe mindre forutsigbarhet i hvordan dataene ser ut, men er en enorm styrke, for det gjør det helt trivielt å utvide modellen over tid.

cjohansen08:03:06

Forøvrig finnes det tusenvis av folk som kan JavaScript også, hvorfor tviholder dere på det lille sære språket på backenden deres? trollface

trollface 4
augustl08:03:11

kanskje man kan kalle det “mongodb-frykten”. Når man har erfart at det finnes databaser hvor det faktisk er trøblete/umulig å modellere ting, hvordan vet man at Datomic ikke er en sånn database når man ikke har erfarne Datomic-folk på teamet?

cjohansen09:03:05

Angående dette med tusenvis av folk: Datomic deler i aller høyeste grad med Clojure at du trenger ikke tilgang på tusenvis av folk, for det er fundamentalt simplere greier, færre bevegelige deler og færre problemer enn med sammenlignbar teknologi. Jeg har vært på Datomic pro-planen i flere år med anledning til å kontakte support - har ikke trengt å gjøre det én eneste gang. Veldig anekdotisk, selvfølgelig.

cjohansen10:03:43

@slipset litt nysgjerrig på dine vurderinger rundt tx-fns. Hva slags constraints bruker du? Datomic kan ikke lagre nil. Datomic sørger for at kryss-referanser er gyldige. Vi bruker av og til Datomics innebyggede compare-and-set for å unngå race conditions. Har laget noen custom tx-fns, men stort sett for å generere en eller annen form for løpenummer.

augustl10:03:32

skulle ønske man kunne “snu på” tx-fns. Altså at man kunne embedde transactoren inne i sitt eget clojure-prosjekt, akkurat sånn man embedder peers, sånn at man ikke trengte å serialisere og shippe Clojure-kode til transactoren

Ivar Refsdal17:04:09

Har du sett https://docs.datomic.com/on-prem/reference/database-functions.html#classpath-functions til transactoren? Ein anna opsjon for å køyre kode frå peer i transactor er https://github.com/ivarref/gen-fn, gitt at all koden du treng ligg i eit enkelt namespace.

👌 2
augustl16:04:05

ah nice, ClassPass functions virker å være det jeg ønsket meg ja

Ivar Refsdal17:04:37

Problemet med det er at du får nedetid for alle som nyttar transaktoren / ingen rolling deploy så vidt eg veit.

Ivar Refsdal11:01:42

Eg lagde ein annan vri på dette som lar deg køyre koden fullt og heilt på peeren: https://gist.github.com/ivarref/c26deae954354ed343719bc5cde06a41 med ein spinning retry som sikrar at ein jobbar mot siste database (ala swap!). Med relativt lite skriveaktivitet burde det gå heilt fint (edit: det køyrer ikkje i produksjon her, me får sjå 🙂. CC @christian767 @augustl

augustl12:01:33

moro! Det er jo et kjekt alternativ det 👍

🧡 1
augustl10:03:56

(…men da i et annet Clojure-prosjekt, og ikke at transactor og peer kjører samme sted)

slipset10:03:18

Dette er jo selvsagt fryktelig skummelt, fordi jeg avslører min uvitenhet og min manglende evne til å sette meg (dypt) inn i Datomic, men eksempelvis: Basically så lagrer vi en graf, dvs noder og kanter. En invariant jeg ønsker meg (som vi ikke har fått på plass ennå) er at en kant ikke kan referere til noder som ikke eksisterer. Dette er historisk sett modellert som at en kant vet hvilke noder den refererer til. Dette er en triviell foreignkey constraint i PG, som jeg kan deklarere.

teodorlu10:03:08

jeg setter stor pris på at du ofrer litt selvhøytidelighet så alle kan lære 🙂

slipset10:03:39

Dette er mitt modus operandi. Si ting som er så dumme at folk ser seg nødt til å reagere.

❤️ 4
👍 2
slipset10:03:55

Dette er ting som vi idag håndhever i Clojure space. Jeg har inntrykk av at dette er ting som man må håndheve i tx-fns?

slipset10:03:24

Det er også helt greit å si at dette er feil måte å modellere det på, og at man ville gjort det på en annen måte i Datomic, men det ville da gjort at en evt migrering ville blitt enda mer risikofylt?

slipset10:03:26

En ting til (som jeg tror akkurat har droppet på plass i Datomic) er at pg lar deg gjøre explain analyze select … som gir deg ganske god innsikt i hvorfor en spørring er treg.

cjohansen10:03:32

Jeg trodde faktisk Datomic håndhevet referanse-constraints, men det ser ikke sånn ut 🤷

magnars10:03:53

du kan ikke ha en referanse til noe som ikke eksisterer

cjohansen10:03:03

har jeg bare uflaks når jeg prøver?

magnars10:03:21

hva prøver du på?

cjohansen10:03:49

(def schema
    [{:db/ident :node/id
      :db/valueType :db.type/uuid
      :db/unique :db.unique/identity
      :db/cardinality :db.cardinality/one}

     {:db/ident :node/edges
      :db/valueType :db.type/ref
      :db/cardinality :db.cardinality/many}])

  (d/create-database "datomic:")
  (def conn (d/connect "datomic:"))

  (d/transact conn schema)

cjohansen10:03:56

(d/transact
   conn
   [{:db/id "node-1"
     :node/id (d/squuid)}

    {:db/id "node-2"
     :node/id (d/squuid)
     :node/edges ["node-1"]}])

cjohansen10:03:59

So far, so good

cjohansen10:03:25

(d/transact
   conn
   [[:db/add 17592186045427 :node/edges 666]])

cjohansen10:03:28

Den siste skulle feila

cjohansen10:03:32

men 666 er kanskje noe?

cjohansen10:03:49

:db.error/tempid-not-an-entity tempid '6999999999999999999' used only as
   value in transaction

cjohansen10:03:07

Så ja, da er det som jeg trodde 🙂

cjohansen10:03:46

Du kan dog ikke type referansen, da må du lage en custom funksjon.

magnars10:03:23

entiteter har jo ikke typer i datomic, bare et utvalg av attributter

cjohansen10:03:34

Hvis det er en graf dere modellerer så er datomic amazing, kan querye grafer rekursivt og greier

slipset10:03:43

Så hvis jeg ønsker at en refereranse alltid har en source og target?

magnars10:03:03

referanser er innebygget i Datomic og har alltid source og target

slipset10:03:35

Ah, altså. Hvis jeg har en user og mitt domene krever at denne alltid har et firstName og et lastName

terjesb09:04:28

Temmelig sent ute til en interessant tråd! Datomic har etter hvert også fått et par facilities som kan hjelpe til her: • attribute predicates: You may want to constrain an attribute value by more than just its storage/representation type. For example, an email address is not just a string, but a string with a particular format. • entity specs: You may want to ensure properties of an entity being asserted, for example ◦ required keys ◦ the creation of related tuples ◦ satisfaction of properties that cut across attributes and the db ◦ An entity spec is a Datomic entity having one or more of ▪︎ (usually) a :db/ident ▪︎ :db.entity/attrs naming https://docs.datomic.com/cloud/schema/schema-reference.html#required-attributes ▪︎ :db.entity/preds naming https://docs.datomic.com/cloud/schema/schema-reference.html#entity-predicates ◦ Entity specs can be asserted or retracted at any time, and will be enforced starting on the transaction after they are asserted. Asserting or retracting an entity spec has no effect on entities that already exist in the database. ◦ Entity specs and :db/ensure are not analogous to traditional SQL constraints: ▪︎ Specs are more flexible, enforcing arbitrary shapes on particular entities without imposing an overall structure on the database. ▪︎ Specs can do more, allowing arbitrary functions of an entity and a database value. ▪︎ Specs must be requested explicitly per transaction+entity, and enforcement is never automatic or retroactive. Det er sikkert helt korrekt som @U07FCNURX sier at dette ‘normalt sett ikke gjøres i Datomic’, kanskje delvis fordi det i starten ikke var gode innebygde funksjoner for dette. Men det kom på plass etter at Nubank tok over;) Jeg har heller ikke brukt dette selv ennå, men tenker at dette absolutt er nyttige saker å ha i verktøykassen..

magnars09:04:22

Jøss, dette var helt nytt for meg. Stilig! Takk for oppklaringen, @U0523NZUF 😄

😄 2
cjohansen09:04:28

> • Specs must be requested explicitly per transaction+entity, and enforcement is never automatic or retroactive. ❤️

❤️ 2
cjohansen09:04:33

Dette ser jo helt nydelig ut!

😄 2
terjesb09:04:07

Topp:) Da må det for sikkerhets skyld også nevnes andre nye ting siden da: • tuples • return maps • analytics via SQL (har to-do på å prøve dette, også at det funker gjennom PGs FDW; iirc kjører Nubank selv trad ETL fra sine mange shards) • qseq • index-pull • xform • io-stats • query-stats • ..og muligens glemt noe God påske:)

augustl09:04:13

oi, det var stilige saker ja!

magnars10:03:37

nei, den slags validering gjøres normalt sett ikke i datomic

slipset10:03:57

Men det er jo ting jeg trenger.

magnars10:03:11

gjør du det?

cjohansen10:03:36

Det er ting som hører hjemme der data opprettes, spør du meg

cjohansen10:03:52

Hva om dere skal begynne å lagre drafts?

cjohansen10:03:15

Jeg tror ikke det er noen fordel å ikke evne å lagre og snakke om data som ikke (enda) er fullstendige

slipset10:03:09

Greia er vel at det er visse ting som vi vet etter 10 år skal være på plass. Vi vet f.eks at en bruker skal ha en epost og et passord.

cjohansen10:03:26

Helt til dere slutter med passord-innlogginger

augustl10:03:30

det er vel noe der ja, i Datomic gjør man mere modellering i queries enn i lagring. Det er jo en del ulemper med å gjøre det absolutt umulig å lagre enkelte typer data

cjohansen10:03:40

Vi har helt gyldige brukere som har hverken epost eller passord

teodorlu10:03:02

@slipset kanskje du kan gi et eksempel på en sekvens handlinger som kan føre til en feilsituasjon du ønsker å unngå hvis du ikke har validering av firstName og lastName i det hele tatt? Er det for å få tidlig nok feedback på at input ikke er gyldig (feilende transaksjon heller at man merker noe en gang senere)? (jeg bare spør av nysgjerrighet, dette er ikke noe jeg føler jeg har veldig god kontroll på)

slipset10:03:42

Jeg ser jo at jeg møter meg selv i døra mhp statisk vs dynamisk typing. Problemet som vi har møtt med mongo er at vi har sett oss nødt til å implementere en del greier i Clojure som er trivielle constraints i PG.

cjohansen10:03:16

For å være litt vanskelig så kan jo det også føre til at man litt for lett lener seg på lagringen for ting som burde håndteres i koden

cjohansen10:03:49

“Brukeren skal ha epost og passord” er en constraint du har i en gitt kontekst. Til og med spec bomma på dette 😅

magnars10:03:52

Det jeg ikke skjønner er kilden til disse dårlige dataene. Hvis det er dårlig kode, så er det vel lite som hindrer det å være like dårlig kode / constraints andre steder. Og hvis det er brukerfeil, så må det da være bedre måter å kommunisere dette til brukeren enn en constraint violation fra databasen?

slipset10:03:24

Dette er jo en applikasjon som har surret og gått i 10 år. Og du kan se for deg at du i starten hadde noe a la POST /api/:collection/ som bare banka ting ned fra frontend uten særlig validering.

slipset10:03:51

Og så har man lagt på fler og fler beskrankninger over tid.

slipset10:03:34

Men det betyr også at man ikke vet hva en foo er. En foo er supersettet av alle dokumentene som ligger i foo kolleksjonen.

magnars10:03:52

det jeg lurte på var: hvilket problem prøver man å stoppe med constraints i databasen? Er det dårlige data fra brukere? Eller er det feil kode?

slipset10:03:14

men mest det siste.

magnars10:03:49

okay, for dårlige data fra brukere burde vel håndteres lenger oppe slik at de kan få en ålreit tilbakemelding

augustl10:03:56

hvorfor er det viktig at det skjer på “command-nivå” og ikke på “query-nivå“? :thinking_face: Man kan jo lage en spørring etter “alle gyldige data per i dag”

magnars10:03:52

men dårlige data fra dårlig kode ... altså, her kan det jo mangle eller være feil constraints, like mye som koden er dårlig ... så da tolker jeg det du sier til at "det er lettere å forstå og enforce constraints i databasen enn det er i kode"

slipset10:03:21

Og man gjør det på et sted

slipset10:03:52

Og hvis noen skulle komme til å fikle med data’n gjennom en database-console, så lever constraint’ene fortsatt.

magnars10:03:59

nettopp, med den ulempen at man mangler konteksten som Christian snakker om, og må operere innenfor de mulighetene databasen gir for constraints

slipset10:03:24

Og skulle man komme til å bygge en ny klient til samme database, så slipper man å huske på å reimplementere de samme constraintene.

cjohansen10:03:45

Jeg har stor sympati for “å gjøre det på ett sted”. Men det er relativt rett frem å sørge for at du kun har ett sted i koden som skriver til databasen. Da kan du gjøre disse forsikringene der - så lenge det trengs.

cjohansen10:03:59

Flere klienter til samme database? Nå må du gi deg 😄

augustl10:03:13

(datomic har heldigvis ingen bra database-consoles så ingen kommer til å skrive data der ihvertfall)

slipset10:03:17

Jeg jobber i den virkelige verden 🙂

cjohansen10:03:23

Det gjør jeg også

magnars10:03:44

du skulle bare visst hvor virkelig vår verden er, @slipset laughsob

laughcry 2
cjohansen10:03:58

hahahahaa, jeg dævver

augustl10:03:39

@slipset men er det kanskje litt en vanesak? Man får jo sjelden modellert alle constraintene man trenger i databasen, det må alltids litt kode til i tillegg. Så er det jo digg at en viss prosent av constraintene blir enforcet alltid uansett, men hva har man egentlig oppnådd?

magnars10:03:09

men ja, jeg ser at det er fordeler med constraints i databasen, nettopp fordi de er eksplisitte og sentraliserte ... fullt mulig å gjøre det i kode også, men da med mer ansvar på skuldrene til utviklerne, som har nok ansvar på skuldrene fra før

slipset10:03:50

Og vi får en slags separasjon/lagdeling mhp hvem som har ansvar for hva.

magnars11:03:42

ja, godt poeng det. Jeg lever jo i en boble av "små team hvor alle gjør alt", slik at den type lagdeling faller litt bort. Gir mye mer mening i større organisasjoner.

cjohansen11:03:24

Håper jeg kan operere i den konteksten resten av min karriere

slipset10:03:59

Helt enig i det. Og vi har endel håndtering av ting i koden for å gi hyggeligere feilemeldinger til brukeren.

augustl10:03:50

det er lettere å representere “ugyldige” tilstander i Datomic enn i postgres. Fordel eller ulempe? 😄

augustl10:03:15

eller, “ufullstendig”, blir vel mere riktig å si, i og med at du ikke bare kan putte hva du vill inn i Datomic

cjohansen10:03:30

datomic stopper deg fra å lagre søppel, det er fint

cjohansen10:03:00

hvilke konstellasjoner som gyldige er kontekstavhengig og et bevegelig mål, og en kjempefordel at ikke lagringen legger føringer for, spør du meg

🎯 2
slipset10:03:14

Men for å dra det over hit igjen. Med Postgres/RDBMS har vi erfaring og vet hvordan problemer løses. Det har vi ikke med Datomic. Det kan vel egentlig sies så enkelt.

magnars10:03:43

Det er en ærlig sak. Ikke så progressiv, men trygg og god.

slipset11:03:11

Som sagt, skulle jeg begynt fra scratch, hadde jeg valgt Datomic hver gang.

magnars11:03:26

Hvis "trygg og god" ble flåsete, så var ikke det i det hele tatt meninga. Kan ikke gå veldig feil med Postgres. 😊

slipset11:03:05

Absolutt ikke oppfattet som flåsete, men en veldig god beskrivelse av hva jeg ønsker å oppnå. Denne migreringen har vært stressende nok som den er.

augustl11:03:32

jeg tror brukere også gjerne ville ønsket å lagre mere crap data i databasen. Et par eksempler: jeg har gjort en haug valg i GUI-et som jeg ikke er ferdig med, men det er ikke gyldig data enda så det ble ikke lagret. Whoops, nettleseren kræsjet, ja ja, må gjøre valgene på nytt. Og jeg hadde en elektriker på besøk en gang, som fikk feil når han sendte inn dataene, og måtte fylle ut alt på nytt. Hadde jo vært fint om han fikk lov til å lagre de crap dataene sine i databasen, og så gjøre det ferdig senere, eller noe sånt. Så lager man en spørring (views i postgres?) etter alle gyldige data. Men så har vi utviklere en aversjon mot crap data, og vil ikke ha det i databasen vår. Hvem er det bra for egentlig?

slipset11:03:17

Derfor bruker vi jsonb kolonner til sånn crap som backenden ikke bryr seg om.

cjohansen11:03:23

Da har du gitt helt avkall på å kunne noe om dataene da

cjohansen11:03:58

du kan ikke bruke de samme spørringene ihvertfall

augustl11:03:02

postgres har en del jsonb-greier, man kan kjøre spørringer som om det var en dokumentdatabase osv

slipset11:03:08

Vi er kun en tabellmigrering unna å lage det til ordentlige kolonner.

slipset11:03:56

Det er mer plunder og heft involvert, men i teorien…

augustl11:03:02

er vel merre en generell beef jeg har med domenemodellering, vi utviklere vil helst bare modellere ferdig/gyldig/perfekt data, og “halvferdig skjema” og “data under arbeid” er liksom ikke ansett som en del av domenet

cjohansen11:03:28

med færre constraints i databasen blir sånt lettere

augustl11:03:49

nettopp, i datomic har man modellert at “attributt X må alltid se ut som dette her”, men strukturene er mere fleksible

cjohansen11:03:12

men ett eller annet sted går grensa for hva man tolererer og heller bare lagrer det i en “jsonb-kolonne” 😅

cjohansen11:03:24

jeg ville ikke hatt ufullstendige telefonnummere i telefonnummer-feltet feks

augustl11:03:54

inspirert av en talk jeg så en gang om et system for sykehus hvor det var en ekstremt viktig del av domenet at man må kunne jobbe med ufullstendige data, man trenger personnummer for å få en eller annen ting “ferdig” men det er også viktig å kunne bestille medisinsk utstyr NÅ og putte inn personnummeret etterpå. Føler litt at utvikler-defaults (putter meg selv i dette settet og, “ryddig data” er digg) gjør at alt for få systemer lages på den måten

cjohansen11:03:19

men å låse ned en entitet/tabell er ganske mye mer begrensende enn å si at “hvert attributt må ha riktig type”

slipset11:03:52

Hørt det eksemplet også. Og det er jo bare dårlig forståelse av domenet/at man bare ser domenet fra en personas perspektiv.

cjohansen11:03:45

Constraints er kontekstuelle

slipset11:03:55

Men igjen. Jeg sier ikke at PG er perfekt, jeg sier bare at det var det minst dårlige valget for oss på det tidspunktet det valget ble tatt. Man kan også argumentere for at valget ble tatt på feil tidspunkt og feil grunnlag.

cjohansen11:03:42

Mener ikke å kristisere dine valg. Syns bare det er trist at dere som Clojure-flaggskip takket nei til Datomic 😢

cjohansen11:03:53

Selvom jeg forstår grunnene

slipset11:03:22

Jeg setter stor pris på at valgene blir kritisert. Da lærer jeg.

augustl11:03:20

kunne vurdert å ha ufullstendige telfonnummere i telefonnummerfeltet og 😄 Hvis feltet skal brukes til å sende ut automatiserte SMS-ser ville jeg nok ikke det. Men hvis feltet skal brukes til å leses av mennesker senere elns, er et dårlig telefonnummer bedre enn ingenting

augustl11:03:42

så kan man jo gjerne ha en spørring som lister opp alle ufulstendige telefonnummere med en anmodning om “plz fix” til brukeren(e)

cjohansen11:03:57

jeg ville heller lagt kruttet i mottaket

augustl11:03:01

må inrømme at jeg aldri har bygget systemer på denne måten, så mulig det er en pipe dream jeg har

cjohansen11:03:48

man må kanskje definere en form for “minimum viable data”

augustl11:03:23

det var et kult konsept 😄

cjohansen11:03:32

er et seks-siffret telefonnummer verdt å spare på? det tar 2 sekunder å gjenskape, og er 100% verdiløst

cjohansen11:03:14

mens et langt elektrikerskjema med noen feil her og der tar lang tid å gjenskape, men kan antageligvis brukes til 8/10 use cases som det står

augustl11:03:44

samtidig er det lame for elektrikeren som står der og har tatt bilder og gjort alt annet riktig å si “fuck deg, du får ikke lov til å lagre alle de andre viktige dataene fordi telefonnummeret er ugyldig”

augustl11:03:16

i Datomic så kunne man jo faktisk ha lagret alle de gyldige attributtene og bare latt være å lagre telefonnummer-feltet

magnars13:03:19

Jeg liker idéen om å ta i mot alle verdiene brukere gir deg, og så heller filtrere på vei ut avhengig av kontekst. Man kunne jo endatil ha laget et datomic-filter over databasen som fjerner ugyldige verdier, og applyet det i de situasjonene der det var viktig.

👌 2
augustl11:03:46

disse diskusjonene er direkte vitamininnsprøyting med høytrykksspyler til min potensielle Datomic-talk på JavaZone i år forresten, keep it coming

slipset11:03:27

Det er også mulig at en del av de feltene vi nå setter not-null constraints på egentlig er foreign keys til andre tabeller og som da egentlig ville vært løst i Datomic.

cjohansen11:03:47

datomic hater nil, så alt er “not nil” 🙂

cjohansen11:03:03

men det er lov at attributtene mangler, så ikke helt sammenlignbart

slipset11:03:15

Men, multi-tennancy historien tror jeg fortsatt ikke jeg har en god forståelse av.

cjohansen11:03:26

du kan kjøre hver tenant i en separat database

slipset11:03:38

Hvor mange databaser kan man ha?

augustl11:03:42

du kan tilogmed joine mellom databaser i Datomic

cjohansen11:03:44

så mange du trenger

slipset11:03:49

en million?

augustl11:03:53

infinity! Tror det var sånn nubank gjorde det, en db per kunde

augustl11:03:26

eneste du må sjonglere med infinity databaser er connections, siden du må ha en connection per db. Så da trenger man en eller annen LRU-pool elns

cjohansen11:03:30

@slipset i prinsippet. hvis du skal ha en million så kan det hende at du har lyst til å ha mer enn én transactor

augustl11:03:22

“single system” virker å være nøkkelordet her. Om man har flere maskiner er det bare å kjøre på. Og avhengig av load osv osv

slipset11:03:22

Svar som dette gjorde vel at jeg ikke følte meg så trygg.

augustl11:03:18

tok visst feil om Nubank: > Nubank employs a microservices architecture with over a dozen independent Datomic databases

cjohansen11:03:52

Har dere en postgres-db per kunde nå @slipset?

slipset11:03:02

Nope, vi har skjema pr kunde

cjohansen11:03:31

altså, helt separat skjema?

cjohansen11:03:42

:thinking_face:

slipset11:03:13

hvis vi har en tabell foo og vi har tusen kunder, så har vi tusen skjema med hver sin foo tabell

cjohansen11:03:28

aha, skjønner

cjohansen11:03:40

det trenger man ikke i datomic, for der er det ikke tabeller

augustl11:03:44

men, å ha millioner av datomic-databaser i Datomic er vel i seg selv ikke et problem. Det er her også spesifikt snakk om datomic cloud, som vel er litt mere begrenset i deployment-topologi

slipset11:03:45

Dette er omtrent akkurat sammes om vi gjør med mongo, men der heter skjema database

slipset11:03:32

Poenget er at vi kan ikke på noen måte tillate at Kodemaker får se dataen’e til Miles og vice versa.

slipset11:03:31

Det er (trivielt) løsbart i PG, på minst tre måter, alle med sine trade offs. Jeg har ikke den oversikten i Datomic, og svarene Cognitect er vage.

augustl11:03:05

dvs, med millioner av datomic-baser så har du to problemer: hvordan spre det noenlunde jevnt utover N transactors, og hvordan håndtere peers og ha en eller annen variant av “arbeidssett i RAM” på en god måte. Det får man nok litt mere ut av boksen med postgres

cjohansen11:03:14

Jeg mistenker at du ikke kan ha like sterk separasjon med egne credentials osv uten å kjøre en transactor per kunde, som nok er lite farbart.

cjohansen11:03:08

Må antageligvis løses i koden.

cjohansen11:03:29

Kunne tilbudt separat transactor som addon 🙂

slipset11:03:13

Uansett. For vår del hadde det vært gunstig om Datomic hadde en blog hvor de beskrev ulike måter å gjøre multi-tenancy på. Type noe som dette https://dev.to/lbelkind/strategies-for-using-postgresql-as-a-database-for-multi-tenant-services-4abd

cjohansen11:03:31

ja, de kunne gjort mye for å selge greia si litt bedre

cjohansen11:03:53

Kult at du posta den hos dem @slipset

slipset11:03:57

Free advice 🙂

slipset11:03:40

Men, ja. De er omtrent like flinke til å selge som andre utviklere.

😄 2
slipset11:03:11

Vi har 19 pers ansatt på marketing, hvorav 4 som kun jobber med innhold.

slipset11:03:39

Trokke Cognitect bruker like stor andel av budsjettet sitt på markedsføring av Datomic.

👍 2
leifericf10:04:45

Jeg hadde (og har fortsatt) lyst til å prøve Datomic. Kikket på dokumentasjonen for en stund siden og så jeg måtte sette opp flere servere, osv. Så tenkte jeg "dette virker komplisert - kanskje senere" 😅

leifericf10:04:15

Mistenker at de hadde kunnet tjent mer på en free/open source forretningsmodell. Tatt betalt for enterprise versjon/support, e.l.

magnars06:04:16

Det var rart. Man trenger absolutt ikke sette opp flere servere. Husker du hvor du leste det?

leifericf17:04:25

Det var på den offisielle nettsiden. Men da var Clojure og Datomic helt nytt for meg, så det er godt mulig jeg misforstod noe. Jeg skal kikke på det igjen med nye øyne!

cjohansen11:03:03

Nei, det kan du si

cjohansen11:03:12

virker egentlig som om de er fornøyde med sin krok i verden

augustl12:03:39

virker som hele Cognitect er uinteresserte i salg og at de koser seg ned å være små

teodorlu12:03:21

Nubank-oppkjøpet endrer jo også litt på landskapet. Kanskje en markdsføringskrone brukt på å selge banken gir mer igjen enn en markedsføringskrone brukt på å selge databasen.