This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-31
Channels
- # announcements (5)
- # babashka (5)
- # beginners (24)
- # calva (21)
- # cherry (1)
- # clerk (20)
- # clj-kondo (3)
- # clj-otel (12)
- # clojure (50)
- # clojure-austin (2)
- # clojure-conj (3)
- # clojure-europe (40)
- # clojure-nl (1)
- # clojure-norway (203)
- # clojure-spec (3)
- # clojure-uk (6)
- # clojurescript (8)
- # conjure (1)
- # datomic (1)
- # deps-new (1)
- # emacs (5)
- # graphql (8)
- # gratitude (5)
- # holy-lambda (16)
- # honeysql (18)
- # hyperfiddle (12)
- # java (1)
- # jobs (1)
- # lsp (24)
- # membrane (8)
- # nbb (1)
- # off-topic (19)
- # portal (28)
- # proletarian (11)
- # rdf (63)
- # re-frame (38)
- # reagent (8)
- # reitit (1)
- # releases (6)
- # remote-jobs (1)
- # scittle (4)
- # shadow-cljs (20)
- # spacemacs (4)
- # sql (7)
- # transit (1)
@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
god morgen! I dag tenker jeg på hvor rart det er at Datomic er så lite utbredt som det er
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/
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
Når alt dette er sagt. Skulle jeg startet en sjappe nå, hadde jeg helt klart valgt Datomic.
Jeg sier videre ikke at jeg har rett i alle punktene, men summen av tvil gjorde at vi valgte det trygge framfor det beste.
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.
> 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.
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…
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
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
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
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
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”.
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.
Forøvrig finnes det tusenvis av folk som kan JavaScript også, hvorfor tviholder dere på det lille sære språket på backenden deres?

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?
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.
@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.
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
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.
Problemet med det er at du får nedetid for alle som nyttar transaktoren / ingen rolling deploy så vidt eg veit.
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
(…men da i et annet Clojure-prosjekt, og ikke at transactor og peer kjører samme sted)
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.
Dette er mitt modus operandi. Si ting som er så dumme at folk ser seg nødt til å reagere.
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?
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?
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.
Jeg trodde faktisk Datomic håndhevet referanse-constraints, men det ser ikke sånn ut 🤷
(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)
(d/transact
conn
[{:db/id "node-1"
:node/id (d/squuid)}
{:db/id "node-2"
:node/id (d/squuid)
:node/edges ["node-1"]}])
:db.error/tempid-not-an-entity tempid '6999999999999999999' used only as
value in transaction
Hvis det er en graf dere modellerer så er datomic amazing, kan querye grafer rekursivt og greier
Ah, altså. Hvis jeg har en user
og mitt domene krever at denne alltid har et firstName
og et lastName
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..
> • Specs must be requested explicitly per transaction+entity, and enforcement is never automatic or retroactive. ❤️
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:)
Jeg tror ikke det er noen fordel å ikke evne å lagre og snakke om data som ikke (enda) er fullstendige
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.
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
@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å)
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.
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
“Brukeren skal ha epost og passord” er en constraint du har i en gitt kontekst. Til og med spec bomma på dette 😅
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?
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.
Men det betyr også at man ikke vet hva en foo
er. En foo
er supersettet av alle dokumentene som ligger i foo
kolleksjonen.
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?
okay, for dårlige data fra brukere burde vel håndteres lenger oppe slik at de kan få en ålreit tilbakemelding
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”
Helt enig, @U07FCNURX
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"
Og hvis noen skulle komme til å fikle med data’n gjennom en database-console, så lever constraint’ene fortsatt.
nettopp, med den ulempen at man mangler konteksten som Christian snakker om, og må operere innenfor de mulighetene databasen gir for constraints
Og skulle man komme til å bygge en ny klient til samme database, så slipper man å huske på å reimplementere de samme constraintene.
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.
(datomic har heldigvis ingen bra database-consoles så ingen kommer til å skrive data der ihvertfall)
@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?
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
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.
Helt enig i det. Og vi har endel håndtering av ting i koden for å gi hyggeligere feilemeldinger til brukeren.
det er lettere å representere “ugyldige” tilstander i Datomic enn i postgres. Fordel eller ulempe? 😄
eller, “ufullstendig”, blir vel mere riktig å si, i og med at du ikke bare kan putte hva du vill inn i Datomic
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
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.
Hvis "trygg og god" ble flåsete, så var ikke det i det hele tatt meninga. Kan ikke gå veldig feil med Postgres. 😊
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.
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?
postgres har en del jsonb-greier, man kan kjøre spørringer som om det var en dokumentdatabase osv
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
nettopp, i datomic har man modellert at “attributt X må alltid se ut som dette her”, men strukturene er mere fleksible
men ett eller annet sted går grensa for hva man tolererer og heller bare lagrer det i en “jsonb-kolonne” 😅
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
men å låse ned en entitet/tabell er ganske mye mer begrensende enn å si at “hvert attributt må ha riktig type”
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.
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.
Mener ikke å kristisere dine valg. Syns bare det er trist at dere som Clojure-flaggskip takket nei til Datomic 😢
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
så kan man jo gjerne ha en spørring som lister opp alle ufulstendige telefonnummere med en anmodning om “plz fix” til brukeren(e)
må inrømme at jeg aldri har bygget systemer på denne måten, så mulig det er en pipe dream jeg har
er et seks-siffret telefonnummer verdt å spare på? det tar 2 sekunder å gjenskape, og er 100% verdiløst
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
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”
i Datomic så kunne man jo faktisk ha lagret alle de gyldige attributtene og bare latt være å lagre telefonnummer-feltet
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.
disse diskusjonene er direkte vitamininnsprøyting med høytrykksspyler til min potensielle Datomic-talk på JavaZone i år forresten, keep it coming
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.
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
@slipset i prinsippet. hvis du skal ha en million så kan det hende at du har lyst til å ha mer enn én transactor
“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
tok visst feil om Nubank: > Nubank employs a microservices architecture with over a dozen independent Datomic databases
hvis vi har en tabell foo
og vi har tusen kunder, så har vi tusen skjema med hver sin foo
tabell
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
Poenget er at vi kan ikke på noen måte tillate at Kodemaker får se dataen’e til Miles og vice versa.
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.
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
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.
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
Trokke Cognitect bruker like stor andel av budsjettet sitt på markedsføring av Datomic.
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" 😅
Mistenker at de hadde kunnet tjent mer på en free/open source forretningsmodell. Tatt betalt for enterprise versjon/support, e.l.
Det var rart. Man trenger absolutt ikke sette opp flere servere. Husker du hvor du leste det?
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!
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.
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.
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.