Is it too expensive to specify an :identifier function that maps keywords in snake_case to kebab-case in clojure.jdbc queries?

@lvbarbosa Define "too expensive"... I would say "Do the right thing" and see how it performs. Only if it isn't fast enough should you make compromises on "the right thing".

@seancorfield not sure, maybe too much for aesthetic purposes.. I love kebab case and it hurts to see keywords using snake case xD

(the default :identifiers function is clojure.string/lower-case by the way -- so there's already a lot of string processing going on if you don't override it!)

got it, so it’s ok to do that conversion

I might get the answer by looking at the code, but I will ask it

Sure it's OK to do whatever conversion you want.

is the mapping done for each record or only once for the entire result-set?

It depends on whether you ask for arrays or maps.

Actually, that's a bit of a misleading answer. It constructs the "column names" once. For a sequence of maps, it zipmaps the column names and the column values for each record.

So the case conversion etc is done once per result set.

(but there's still the map construction being done for each record)

understood

Seriously tho', "do the right thing" and if you think your program is "too slow" then profile it. If you're already interacting with a SQL database, I doubt a bit of string manipulation is going to be your bottleneck!

Otherwise it's just premature optimization.

thanks @seancorfield, and btw, nice work on clojure.java.jdbc! I am reading the “Clojure Programming” book by Emerick et. al. and there are references to the library (as you probably already know). The book is a bit outdated on that, since the library has evolved, but the official docs are helping me a lot

Even the community docs are bit outdated -- no documentation on reducible-query yet, for example.

Using compojure, just have the one route and nothing fancy happening

When you find yourself propagating context args down a call chain (e.g runtime dependencies, cached values that are accumulated along the way etc.) , do you use a single context map? Would you pass it as the first arg to each function or as the last?

yes, a single map, as the first arg always

@noisesmith Do you also return a context map from these functions, perhaps accumulating data and passing it along with threading macro?

no, I don't return the context map from functions that use it - I can see how that pattern could be useful, but it also makes the context map a full fledged arbitrary state argument

Hey! I'm reading the about page for clojure.spec (https://clojure.org/about/spec) and came upon this paragraph (after showing how a spec for a Map is written)

> One of the most visible differences between spec and other systems is that there is no place in that map spec for specifying the values e.g. ::x can take. It is the (enforced) opinion of spec that the specification of values associated with a namespaced keyword, like :my.ns/k, should be registered under that keyword itself, and applied in any map in which that keyword appears. There are a number of advantages to this:

and I was wondering what exactly is meant by "specification of values associated with a namespaced keyword should be registered under that keyword itself"

If you give the keyword global meaning in your program, you can register that meaning once and rely upon it

This necessitates having the keyword be namespaced

ah I read a bit further where spec/def is shown

one consequence is that maps specs don't have to be so redundant in describing their attribute <-> value bindings

so that's used to clarify the specification for a key value on the namespace?

yeah, you just say the attribute

and not on the spec of the map

aha

"This is a map that requires a :foo.bar/baz and a :quux/bar" <- a sufficient map spec

cool, makes sense considering the dynamism of clojure

thanks!

RE: JS Interop Question I have a global JS array

// index.js
var players = ["James", "Karen"]

not sure if it’s the best way, but you can use something like (.push js/players "Alexandra")

hi. i'm trying to use the official java elasticsearch client, and it fails on a client creation with an error message i cannot understand this snippet (RestClient/builder (HttpHost. "localhost" 9200)) results in this error message ClassCastException org.apache.http.HttpHost cannot be cast to [Lorg.apache.http.HttpHost; wikimodels-preserver.core/eval12167 (form-init2602301893053636779.clj:83) what should [Lorg.apache... mean? ‎ why [L ?

thanks in advance

the [L prefix if for java arrays

so it’s looking for a java array of type org.apache.http.HttpHost in this example

so varargs from java should be represented as a vector in clojure right

i’m not sure if you can use a vector

i think it has to be a java array

vector didnt work

(RestClient/builder (to-array [(HttpHost. "localhost" 9200)]))

ok let me try. thanks a lot for an idea @smith.adriane

or if that doesn’t work, (RestClient/builder (into-array org.apache.http.HttpHost [(HttpHost. "localhost" 9200)]))

that first one didn't work with

[Ljava.lang.Object; cannot be cast to [Lorg.apache.http.HttpHost

ok, you may need to use into-array with the type instead

sorry about that

that one worked. now i have another question please

why org.apache.http.HttpHost there?

why this full name (or how is that called properly)? i mean i've imported HttpHost

that was me just copy and pasting

HttpHost is fine

if you have, you can just use HttpHost - import only changes the rules for lookup, so as long as it looks up the right thing you can always use the briefer form

^^

what he said

also, you can use classes without import- the vm auto-loads on usage, import just makes it more terse

ah i see

thanks, @smith.adriane @noisesmith

this only works with classes though, not namespaces (which are a clojure thing and need require etc.)

right, makes sense