This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-23
Channels
- # beginners (169)
- # boot (8)
- # cider (20)
- # cljdoc (66)
- # cljs-dev (1)
- # cljsrn (1)
- # clojure (185)
- # clojure-greece (11)
- # clojure-italy (16)
- # clojure-nl (5)
- # clojure-spec (16)
- # clojure-uk (39)
- # clojurescript (11)
- # cursive (26)
- # data-science (2)
- # datavis (1)
- # datomic (40)
- # emacs (10)
- # figwheel-main (64)
- # graphql (10)
- # hyperfiddle (1)
- # jobs (2)
- # leiningen (9)
- # luminus (3)
- # nyc (1)
- # off-topic (19)
- # om (1)
- # onyx (6)
- # pedestal (2)
- # re-frame (35)
- # reagent (17)
- # ring-swagger (9)
- # rum (1)
- # shadow-cljs (42)
- # spacemacs (8)
- # specter (7)
- # tools-deps (4)
- # yada (6)
I have a problem with clojure.java.jdbc.spec
, namely when calling query
fn which is instrumented with this spec:
(s/def ::result-set-fn (s/fspec :args (s/cat :rs (s/coll-of any?))
:ret any?))
It calls my result set fn with a bunch of garbageSo when callbacks have a fspec defined, they get called with random data if they are instrumented?
that's how the function is validated
it is a common source of surprise
I guess i need to instrument just a specific ns
Is there a way (or another function) to have spec/explain
return just the spec errors and not the original data as well?
@samueldev I was about to do just that but then decided to check if I had missed something that already existed. Guess that’s a no… thx!
@roklenarcic Yeah, I may revisit some of those fspec
s in clojure.java.jdbc.spec
as I get more feedback from people. As @gfredericks says, the behavior you're seeing is what clojure.spec
instrumentation is intended to do, but it can be surprising at first. And of course your specific :result-set-fn
may well not accept any old collection -- but given that :row-fn
can transform the result set data into, essentially, an arbitrary collection of any type of element, the :result-set-fn
could potentially be called on any?
types... We don't have parameterized types so we can't constrain the row function to map? -> T
and then the result set function to coll-of T -> U
...
This surprised me
1. In a CLJS namespace, define a function with a name that matches a valid HTML tag (e.g. "table" or "br" or whatever)
2. Create an (s/fdef ...) spec for it.
Result: every function in that namespace now evaluates to nil.
Just a local fluke in my current project, or something that other people can reproduce?
If the latter, known issue, or new?