Fork me on GitHub

A new piece of documentation for implementing require + load-file was just added to sci:

👀 4

Podcast about babashka:

💯 12

So it's hidden behind a feature flag. I'm open to include it by default if there is enough demand for it. Also: should JDBC + psql support be included by default, or also feature-flagged?


If psql users would like a version of bb that has support for it, they can compile a version of it for their companies use. Does that make sense?


This would also allow bb to add support for mysql, etc, without creating "bloat" for other bb users?


Do you plan to release binaries as well? Or you stick to current process?


I'm going back and forth between ideas like: 1) if bb would always include hsqldb, it would allow the ecosystem to grow in interesting ways... but when will we hit the CI limit again.. and where does it end? Should we also include sqlite, then we have two of those embedded things? 2) sql usage is quite niche for scripting, let's keep things clean, if users need it they can compile it


@ales.najmann If the feature is optional, there will not be a seperate distro for that I think, since maintaining all permutations of distros is a pain

👍 8

"sql usage is quite niche for scripting" -> let's think big, bb could change the status quo. I don't know hsqldb but I'd definitely use sqlite for scripts if it was that easily accesible.


hsqldb is similar to sqlite as in a mature embedded database


I found an example for sqlite here: which worked:

$ ./build/graal/sqlite
It Works from SQLITE!!!
so using this information, I might be able to figure sqlite out...

👀 4

so this "works" now:

(def db "jdbc:sqlite:/tmp/db01.db")

(defn query [q]
  (jdbc/execute! db [q]))

(prn (query "SELECT 'It Works from SQLITE!!!' AS MSG "))
but it hangs, it doesn't return anything.


ok, here are the results for sqlite so far: if anyone has an idea what to try next, you're welcome to take a peek


Riffing on the babashka example that shells out to sqlite3, I’m pretty happy with this…

(let [{:keys [exit err out]} (shell/sh "sqlite3" "-csv" db (sql q))]
    (if (zero? exit)
      (csv/read-csv out)
      (throw (ex-info (str "SQL error: " err) {}))))
Perhaps clj-jdbc could fill the role of sqlite3 here, a kind of Swiss army knife of database connectivity with a consistent interface.


feels like making the JDBC family optional is making more sense


interesting idea to make babashka.sqlite that just shells out


could do that possibly with mysql and psql


I feel like babashka.curl is akin to java interop, but with shell instead


like there could be a module that wraps the aws cli to but makes the inputs and outputs nice


yeah, and these libraries can be created by "babashka community" members, and if they become popular enough, they can eventually be adopted as part of bb


given the relative small added size of the postgres driver to bb and given the size of their community (and that I use it myself at work, and I'm very satisfied with it)) it might be OK just adopt that one as the default supported server db and make the rest optional. adopting hsqldb as the default built-in embedded database would be cool, but probably it makes sense to wait until enough people see the need for it.


maybe it would be nice to have a group of babashka stakeholders representing the user base, companies that are seriously using it in their businesses, so it's more clear to what direction babashka should grow and what it should or should not include by default


Keeping postgres support in bb would maybe also steer people from mysql to postgres. I wouldn't mind that at all 😉


Haha. Too true.

Darin Douglass20:04:52

Yeah shell out and parts output feels natural for a scripting situation. That’s what I was doing before jdbc came along. The library -> inclusion into bb core feels a natural extension of clojure incubator approach.