I've read that postgres is a better documents store than mongo

@seancorfield 👍 for the feedback. and another 👍 for maintaining c.j.jdbc. All the methods (should?) be taking db-spec as an optional first argument. I'm just not a fan of manually passing in the db-spec to every command. I can count the number of times I've had two databases on my nose. But perhaps I should remove that 'feature' and leave it up to users. Is it fine to throw arbitrary junk into the db-spec ? Need to record the name of the database somewhere.

@xlevus those DB spec maps already have :dbname -- do you mean something else for the name?

> I'm just not a fan of manually passing in the db-spec to every command. You'll get used to it as you do more Clojure 🙂 but I understand how convenient the dynamic global vars seem when you first get started. CongoMongo and Monger both used to do this but Monger got rewritten to have the DB connection passed everywhere. CongoMongo still hasn't (mostly because I maintain it but I'm moving away from MongoDB and don't have the enthusiasm for the rewrite -- I simply point people at Monger instead... it's better maintained and better documented anyway!).

my plan was to let the project be easily migratable away from (because lets face it, the entire project is kinda a hack), and to sit amongst your own tables. so I was trying to implement a way to let the user name the tables. Which is easy with a dynamic global, but hard without. Unless, you just say "stick a :docufant key in your db-spec and it'll work out the tablename from there"

@xlevus Not sure I understand what you mean by "name the tables"... The tables have names already...?

@xlevus in theory the idiom in clojure is that you can add namespaced keys to a map in order to extend it, and they will be ignored Not all libraries do this. But it may work.

clojure.java.jdbc lets you specify a :qualifier option that will add a namespace qualifier to identifiers returned by JDBC operations.

You can put :qualifier into the db-spec so it applies to all operations.

I don't understand what that means @seancorfield

(in general the db-spec can contain defaults for any options you can pass elsewhere to clojure.java.jdbc)

(jdbc/query db-spec ["select id,name from fruit"] {:qualifier "fresh"})
=> ({:fresh/id 1 :fresh/name "Apple"})

But you could put the option in the db-spec and have it apply automatically:

(def db-spec {:dbtype "..." :dbname "..." :qualifier "fresh" :user "..." :password "..."})
(jdbc/query db-spec ["select id,name from fruit"])
=> ({:fresh/id 1 :fresh/name "Apple"})

@seancorfield that does indeed. Why is that there?

my library specifies it's own tables, which the user doesn't actually ever need to know the name of. so far is just hard-coded to be called docufant. but conceivably a user may want to call something else, (either they're using the library twice, or just want the table to be called document)

@dominicm Not sure what you're asking? Why does clojure.java.jdbc provide an option for automatically producing namespace-qualified keywords in result sets?

@seancorfield I'm curious what the use-case was which added (into {} (map (fn [[k v]])) to jdbc.

@xlevus I would probably tackle that by have an opts (options) argument that can be passed into library function calls, including that utility table's name, and have it default to docufant -- that's much more idiomatic.

@dominicm I don't understand your question at all... sorry...

hm, ok.

👍 ta

@seancorfield the qualifier option seems odd to me. Hugely so. For what reason is it there? I can't see why the response to the request wouldn't involve telling the requester to namespace the keys themselves.

@dominicm c.j.j has always "owned" constructing the names of the keys in the maps returned from result sets. It can produce strings, keywords, it can transform those names (by default it makes them lower case, for example).

So namespace-qualification is just part of the name construction.

c.j.j has :identifiers and :entities options which accept functions that represent the naming strategies.

Since c.j.j is already turning ResultSet objects into sequences of hash maps, it doesn't make sense to force a user to re-iterate that entire data structure to rename things, when it could be done upfront and efficiently as part of the ResultSet processing in the first place... ¯\(ツ)/¯