This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-26
Channels
- # announcements (2)
- # beginners (46)
- # calva (16)
- # cider (5)
- # clj-kondo (1)
- # cljdoc (11)
- # cljsrn (4)
- # clojure (42)
- # clojure-dev (2)
- # clojure-spec (6)
- # clojure-uk (1)
- # clojurescript (18)
- # cursive (7)
- # datomic (18)
- # duct (1)
- # fulcro (11)
- # graalvm (1)
- # hoplon (9)
- # leiningen (1)
- # off-topic (8)
- # shadow-cljs (16)
- # spacemacs (9)
- # specter (3)
- # sql (33)
- # vim (3)
- # xtdb (8)
I'm using jdbc.next When I run a simple query, it returns with nil values. Something happened after this? http://corfield.org/blog/2018/12/06/null-nilable-optionality/
Yeah, I gave that a lot of thought and decided, for the first stable release, to keep nil
values in hash maps, based on a lot of feedback I got on Slack, Zulip, and elsewhere.
What I will probably do is add a "builder" function for hash maps that omits nil
values, so folks can opt into this behavior.
You could create a variant of MapResultSetBuilder
with this function altered:
(with-column [this row i]
(assoc! row
(nth cols (dec i))
(read-column-by-index (.getObject rs ^Integer i) rsmeta i)))
so that it called (.getObject ..)
but just returned row
untouched if that was nil
.@souenzzo Would you prefer to get nil
back or for the keys to be omitted for nil
values?
Reasons not to do it by default include: it doesn't work at all for the as-arrays
still builder; it won't necessarily work if you try to update!
based on the result of an execute-one!
/ query
(the missing columns would not be updated, whereas with nil
they would explicitly be set to NULL
)...
As a #datomic user, nil in database is a strange thing to me. But in SQL, nil in database is a thing I do not have enough experience to prefer anything ATM
Yeah, a lot of people argued that NULL
was a thing in SQL and needed to be surfaced in a lot of cases.
I'm comfortable with the extensibility of next.jdbc
that adding new behaviors via builders is a good way to go. The tests include a builder that produces records for rows, for example.
I'm doing something wrong? [next.jdbc :as jdbc]
(let [db (jdbc/get-datasource db)
db* (jdbc/get-connection db {})
tx (jdbc/prepare db* ["SELECT authed FROM app_session"]
{:builder-fn next.jdbc.result-set/as-unqualified-maps})]
(jdbc/execute! tx))
=> [#:app_session{:authed nil} #:app_session{:authed nil}]
opts
from get-connection
is undocumented
is it the right way to use?
(let [db (jdbc/get-datasource db)
db* (jdbc/get-connection db {:builder-fn rs/as-unqualified-maps})]
(jdbc/execute! db* ["SELECT authed FROM app_session"]))
If is, it's not workingprepare
doesn't create a result set so :builder-fn
makes no sense there.
execute!
does create a result set, so :builder-fn
does make sense there.
Not sure what you're asking about get-connection
? The options that make sense for get-connection
are documented here https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-beta1/doc/all-the-options
Remember that get-connection
produces a java.sql.Connection
object -- so only options that can affect that object make sense.
What you want is
(let [db (jdbc/get-datasource db)
db* (jdbc/get-connection db {})
tx (jdbc/prepare db* ["SELECT authed FROM app_session"])]
(jdbc/execute! tx {:builder-fn next.jdbc.result-set/as-unqualified-maps}))
=> [{:authed nil} {:authed nil}]
I was browsing the wiki and the code, the answer was in the cljdoc 😅
cljdoc looks awesome! Thks!
But for me, choose a builder-fn in get-connection
to do not care about it in the execute!
may be a nice feature
What you want is
(let [db (jdbc/get-datasource db)
db* (jdbc/get-connection db {})
tx (jdbc/prepare db* ["SELECT authed FROM app_session"])]
(jdbc/execute! tx {:builder-fn next.jdbc.result-set/as-unqualified-maps}))
=> [{:authed nil} {:authed nil}]
@souenzzo Remember that:
• get-datasource
produces a Java object, javax.sql.DataSource
• get-connection
produces a Java object, java.sql.Connection
• prepare
produces a Java object, java.sql.PreparedStatement
And none of those will carry options through the to "next" call you make.
I've added some Option Handling notes to the Migration from clojure.java.jdbc
docs https://github.com/seancorfield/next-jdbc/blob/master/doc/migration-from-clojure-java-jdbc.md#option-handling
@seancorfield I have a question for next.jdbc
.
looks like I can only give sql-params to next.jdbc/plan
.
but there are functions in next.jdbc.sql
.
why not these functions return sql-params
that can be used in either next.jdbc/execute!
or next.jdbc/plan
?
@doglooksgood Because the sql+params they build is consumed by the API-level functions in that namespace -- they wouldn't be useful outside that namespace.
That whole namespace is merely a convenience for a handful of common operations. They're not the primary API. And if you want to build sql+params, use something like HoneySQL...
plan
, execute-one!
, and execute!
all take sql+params, as does prepare
.
HoneySQL (and similar DSLs) produce sql+params. Several clojure.java.jdbc
functions accept that. next.jdbc
's primary API accepts that.
@doglooksgood Did that answer your question?
is there any managed service for postgres that anyone can recommend? I am currently on datomic-cloud for my dev-environment but I am not too sure about it anymore since i know it won't play nice with GDPR in Europe.
https://vvvvalvalval.github.io/posts/2018-05-01-making-a-datomic-system-gdpr-compliant.html
I am on AWS so I guess https://aws.amazon.com/rds/postgresql/ would be the obvious choice.
yep RDS is good, would recommend before any others if you’re already drinking the AWS kool-aid
you might also explore how datomic cloud can support GDPR. it seems like excision would allow you to comply? not an expert in either Datomic or GDPR
might be sounding like an AA meeting but "i'm martin and i've been using rds for a while now". not as flexible as your own setup but dead easy to get up and running.