“men det betyr jo at det skjer ett nettverkskall til databasen hver iterasjon i kallet til map” - jeg har en indre “person som er forutintatt og ikke kan Datomic” når jeg leser postene deres 😄

Litt nysgjerrig på hva @U04V5VAUN tenker om dette? Vi har jo tidligere diskutert SQL vs ymse

Hva slipset synes om entitets api’et til Datomic?

Tja, kanskje det? Egentlig dette:

Vs tilsvarende SQL

😛 Husker jeg rynket litt på nesen da jeg så Stuart Halloway presentere /_ syntaksen på NDC Oslo for en haug med år siden…

hehe

Ja, det er bittelitt syntaks. Men noen orders of magnitude mindre syntaks enn en SQL-streng 😅

Lurer på hvordan det skulle sett ut for å unngå syntaks :thinking_face: Kanskje man skulle fått lov til å navngi reversen i skjeamet, det hadde vært noe - men da kommer det ikke automatisk lenger.

Evt begge deler

Jeg tror det blir litt epler og pærer lissom.

Begge handler om å aksessere dataene dine fra lagring?

Men klart, det er litt epler og pærer i hvor ressursbruken går

Jo, men hva er det egentlig vi gjør her. Jeg har altså et poststed, og så vil jeg finne ut hvor mange gater det er der?

Antall gater i de kommunene et gitt postnummer ligger i

Kanskje et noe søkt tall, men stryk count-en, så har vi dette i vår kodebase for å finne matrikkeladresse ut fra en “håndskrevet adresse”

ardoq_customers=# \d gate;
                  Table "public.gate"
   Column    |  Type   | Collation | Nullable | Default
-------------+---------+-----------+----------+---------
 id          | integer |           | not null |
 navn        | text    |           |          |
 poststed_id | integer |           | not null |

ardoq_customers=# \d poststed
               Table "public.poststed"
  Column  |  Type   | Collation | Nullable | Default
----------+---------+-----------+----------+---------
 id       | integer |           | not null |
 postnr   | text    |           |          |
 poststed | text    |           |          |

ardoq_customers=# select count(*) from gate where poststed_id in (select id from poststed where poststed = 'OSLO');
 count
-------
     1
(1 row)

ardoq_customers=#

Så kan man myse litt å tenke seg til hvordan dette ville blitt i honey. Men det er klart at dette er mye nærmere query apiet til Datomic enn entitets apiet.

Dette er ikke samme spørring - du hoppa over kommunen.

Poststed Oslo er ikke det samme som Oslo kommune

Man kan, hvis man vil være riktig vrang, si at entitets apiet til Datomic er et slags ORM der du , fordi data’ene ligger på klienten og ikke på en server langt unna, slipper unna all problematikk med n+1

Det er ikke en ORM, fordi det er ikke noen M

Men ja, du slipper all problematikken fordi dataene ligger på klienten

Og gjør en trade-off i hvor du bruker ressursene

Flisespikkeri (dette med ikke O) greia med hibernate var jo at du kunne “navigere” relasjoner på domene objektene dine, noe jeg ville påstå at gjøres i den blogposten.

Absolutt

Men nettverkstrafikken er helt annerledes, og dataaksessen er heller ikke sammenlignbar. I Hibernate skaper du en illusjon om å kunne gjøre det der mot en durabelig kostnad over nettverk. I Datomic er det sånn dataene ligger, så du henter bare de tingene du trenger å prosessere.

Men dette er egentlig litt på siden av “hvilken leamikk er hyggeligst å grave i dataene sine med” 😄

ardoq_customers=# select count(*) from gate where poststed_id in (select id from poststed where kommunenr in (select id from kommune where navn = 'OSLO'));
 count
-------
     1
(1 row)

ardoq_customers=#

Selvom dette begynner å bli penere med joins.

Men som sagt, dette er langt nærmere query apiet til Datomic.

Ja, ihvertfall om du skriver det med joins

Jeg merker meg at jeg har helt gått over til å bruke sub-selects, det passer mye bedre sånn som jeg tenker.

Datalog og SQL opererer i samme landskap vil jeg si. Datalog fungerer bedre for min hjerne, men det er sikkert subjektivt (som forsåvidt også entity-kodeeksempelet)

Datalog tegner visuelt ut hvordan jeg ville traversert grafen for å finne dataene jeg leter etter. Har alltid strevd med SQL fordi jeg ikke har hatt noen god mental modell. Enig i at sub-spørringer er lettere å lese enn joins.

https://github.com/korma/Korma er et slags entitetsoverbygg for SQL i Clojure. Har ikke brukt det. Heller ikke vurdert det noe særlig.

Sånn sminke slutta jeg med da jeg sa meg ferdig med Ruby 😅

🙂

mye mer sansen for Honey, som faktisk gjør et løft ved å la deg manipulere datastrukturer heller enn makroer og strenger

Jepp. Jeg er veldig glad i nettopp de aspektene ved honey. Det er i allefall sinnsykt mye bedre enn å herje med strenger.

Jepp. Og med datalog er det native til databasen ❤️ 😄

🙂

vi har sql-a en del for å grave i gammal data, og honey gjorde det veldig mye mer levelig. Holdt på å dævve etter første dagen med streng templates, for en utdatert måte å jobbe på

Jeg har hatt litt lyst til å prøve ut https://github.com/igrishaev/pg2

Snakker jo ikke honey direkte, men ungår såvidt jeg kan forstå å gjøre om til strenger først.

jeg ser bare strenger?

https://github.com/igrishaev/pg2?tab=readme-ov-file#honeysql-integration--shortcuts

https://github.com/igrishaev/pg2?tab=readme-ov-file#prepare

Skjønner

Men hvis jeg ikke husker helt feil. Postgres har to netverks protokoller en binær og en tekst. JDBC bruker tekst protokollen, der du sender sql strings, mens dette biblioteket bruker den binære protokollen.

Høres besparende ut