not-empty fins også og er flotters om man bryr seg om listetypen

Nei, fordi de løser ikke et stort nok problem. Det er veldig lett å lage en query builder hvis man vet the basics av SQL escaping. En annen ting er at vi har begynt å bruke mye JSON querier, og slike verktøy har ofte veldig lite støtte for det. En annen grunn er at de ofte gjør en dårlig jobb med å skille query parametere fra query text, og gjør det lett å gjøre det som er feil: å variere query text når det er unødvendig. For eksempel, bake in in-liste verdier, osv.

Men hvis jeg skulle jobbe på et lite/kortvarig prosjekt, og jeg trengte en query builder med veldig dynamisk SQL som ikke kunne vært statisk, så ville jeg sikkert brukt det.

Bruker PG og Honey. Trokke jeg hadde vurdert en sql database hvis det ikke var for Honey. Bruker en del JSON og hadde blitt gal hvis jeg hadde måttet knote det til for hånd.

Kult at vi er uenige!

Brukar ez-database som låter mig använda HoneySQL, HugSQL eller strängar

Bruker HoneySQL med Postgres. Liker at det er Clojure-kode/EDN man skriver, ikke SQL i en streng. Paredit fungerer, f.eks. Litt som å skrive HTML med Hiccup-syntaks.

@U08JKUHA9 honey-sql er vel en query-builder? Har du mekka din egen?

Jeg har knota litt rundt i honey-sql koden og jeg blir fort litt lost. Men det er kanskje fordi den er superduper generell og skal funke for alt i alle databaser?

Er veldig glad for at jeg slipper a skrive det selv, selvom

{:select :foo :from :bar :where [:= :a 2]}

select foo from bar where a = 2

Men plutselig, så kommer noen (jeg) og skal ta i bruk rekursive CTE’er og da er det digg at det allerede er gjort.

Jeg hadde et vagt minne av å ha blitt fortalt om HugSQL, eller konseptet i den, for en tid tilbake og trodde jeg ville like det. Men da jeg fant funksjonsnavn i kommentarene på en sql-fil kjente jeg at dette nok ikke er noe for meg 😅

Vi har ikke så mye SQL, og kommer langt med jdbc.next. Kan se for meg at jeg ville vurdert Honey dersom jeg skulle ha mye SQL.

Syntes HugSQL var kult da det kom ut, men ser i ettertid at det har et relativt begrenset bruksområde, som etter mitt skjønn er hvis du har gigaschvære analytics spørringer som du ikke komponerer med noe som helst.

Kanskje. Selv da er det kanskje like greit å hive spørringen i en fil og bare lage en funksjon som leser den inn?

Det var et lite helvete å forholde seg til disse “magiske” funksjonene som dukket opp i koden.

Ja, det kan jeg se for meg

Har noe HugSQL i koden fra gammelt av. I utgangspunktet er det en vakker idé, at du bare skriver SQL i en egen fil, men det blir for mye magi, som du er inne på. Det er en makro du må kalle som leser disse .sql-filene og lager funksjoner (med navn fra kommentarene) i navnerommet den kalles i. Blir vanskelig å navigere i editoren, og i det hele tatt uoversiktlig.

@U9MKYDN4Q Ja

Det er litt skuffende, men sånn i ettertid så viser det seg at det enkle ofte er det aller, aller beste.

Overraskende hvor ofte det er konklusjonen 😄

Forøvrig, så tror jeg nesten at vi har bygget noe som ligner på var egen, sammensausete versjon av Korma og datomics entity api.

😄

Hva er Korma?

https://github.com/korma/Korma

Selvom jeg ser at det ikke er det vi har gjort. Det vi har endt opp med er en slags config pr entitet.

Korma ser ut til å besvare spørsmålet “hva om jeg vil generere SQL med masse makroer?”

vi bruker hugsql, helt OK, ingen store innvendinger, fint å ha SQL-en i SQL-filer, har sitt eget enkle syntaks til å ekskludere eller inkludere ting fra spørringen avhengig av parametere, osv. Og om man bruker hugsql er det jo ingenting som stopper deg fra å droppe ned til jdbc.next direkte om den ikke dekker en eller annen use case som dukker opp

også kjekt at man kan navngi spørringene i sql-fila og annotere defaults som “her skal du bare hente ut første rad eller nil”, “her skal du hente ut en liste”, osv

eksempel på conditionals. Litt “artig”, men i bunn og grunn er det jo bare clj i sql-fil via en kommentar. Funker helt fint til enkle ting, og som sagt er det jo bare å la være å bruke det i tilfeller hvor det blir for mye køk og det er bedre å lage sql-string fra clojure

> clj i sql-fil via en kommentar 😬 😬 😬

Dette er for clever for min smak

fin tradeoff med at man får sql-kodehjelp i en .sql-fil osv egentlig, men bør bare brukes til helt helt enkle greier ja

ellers er jo sql et språk som også har conditionals, litt avhengig av use case selvfølgelig 🙂

> honey-sql er vel en query-builder? Har du mekka din egen? @U04V5VAUN Ja. En som er kanskje ikke så langt fra Honey (bruker maps, vectors, og keywords) i et parr-hundre linjer av Clojure, og det var nok til å skrive en hel GraphQL query -> SQL translation lag. Så med query building trenger man ikke så mye Clojure kode for å løse problemet. Kunne kanksje brukt Honey for det også, men jeg er litt redd for å begynne med en library, og da finne ut senere at den ikke dekker behovet.

En annen ting - jeg synes egentlig det er feil å release en query builder hvis man ikke også releaser et SQL -> query builder syntax tool. Kanskje litt kresen 😆.