Automatic camel casing

I type what I mean, so do what I mean

Not sure what you mean @U09LZR36F HoneySQL doesn't do camel casing...

It does, of table names

Nope

user=> (require '[honeysql.helpers :refer :all] '[honeysql.core :as h])
WARNING: update already refers to: #'clojure.core/update in namespace: user, being replaced by: #'honeysql.helpers/update
nil
user=> (-> (select :*) (from :some-table) (h/format))
["SELECT * FROM some_table"]
user=> (-> (select :*) (from :some_table) (h/format))
["SELECT * FROM some_table"]
user=> 

user=> (-> (select :*) (from :some-table) (h/format :allow-dashed-names? true :quoting :mysql))
["SELECT * FROM `some-table`"]
user=> 

Sorry, that's what I meant (and forgot, I knew it changed).

I know I can, but I find that kind of api design very frustrating. Maybe it's just me. I prefer the closest relationship between what I type and what happens possible.

If you don't ask for quoting, the - is going to be illegal in most database tho', right?

(and "good morning, Dominic!" 🙂 )

I mostly agree with you tho'... this is why next.jdbc's default is "as-is" (albeit qualified keywords) rather than clojure.java.jdbc's somewhat weird default of forcing lower-case on columns.

Not in mysql, as I discovered when I was helping someone :)

Hahaha... well, much as I love MySQL, it's a weird, non-standard beast.

Yeah, love that about next.jdbc, I got rather frustrated using h2 with c.j.j

Morning :) I'm in my new house and very excited. Despite limited sleep.

It is. I'm ready to burn it with fire to be totally honest :)

Like the table names are case-sensitive if the O/S is case-sensitive but column names are case-insensitive and even value equality on strings is case-insensitive (by default, at least on early versions).

I must admit, because we have some weird legacy conventions in our MySQL DB, I've started to adopt these as default options:

(def ^:private jdbc-options
  "The default set of options to pass to next.jdbc so that we get
  kebab-case identifiers and snake_case entities."
  {:builder-fn rs/as-modified-maps
   :column-fn ->snake_case
   :label-fn ->kebab-case
   :qualifier-fn ->kebab-case
   :table-fn ->snake_case})

This doesn't help with all of our tables, but it makes our more recent decisions more tenable. We have a lot of legacy camelCase table and column names 😞 I hate our database to be honest!

Of course, if we were starting fresh, we'd probably use Datomic 🙂

Monsters

I'm looking forward to a stable crux, a lot of my ideas are "oh, let's store this for later. Might be handy".

That's great to hear @U11EL3P9U -- I'll try not to break it with any future changes 😉

I love tiling window managers… Having tried almost all of them XMonad was my favourite. Having to use Amethyst on macos, which is a poor substitute for any of the proper ones.

🙂

once you use tiling, you won't go back 🙂

this is is recurring theme for me.

I almost always experience this same remorse after introducing optional parameters

I assume its not just me....

under what circumstances has optional params to be a good choice?

(If any)

well you could do (defn my-fn [param1 & [{:keys [opt1 opt2]}]] ...) for a similar result

although i favour the dual-arity version, but only 'cos i find it easier to read and "easier to read" is partly a feature of familiarity, so it's not necessarily a particularly sound reason

i just agd over our codebase with (\ |\[)\&\ and found a couple of useful cases for rest-args

[1] macros with [... & body]

[2] proxy functions with [& args] which forward all their args to another fn

but we don't have any use of the map destructure on rest-args - i really don't like it

I use rest args a fair bit