This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (5)
- # beginners (38)
- # boot (197)
- # carry (7)
- # clara (3)
- # cljs-dev (7)
- # cljsjs (6)
- # cljsrn (24)
- # clojure (39)
- # clojure-art (10)
- # clojure-austin (7)
- # clojure-dusseldorf (1)
- # clojure-italy (8)
- # clojure-russia (89)
- # clojure-spec (119)
- # clojure-taiwan (1)
- # clojure-uk (19)
- # clojurescript (104)
- # community-development (2)
- # conf-proposals (22)
- # copenhagen-clojurians (8)
- # cursive (2)
- # datomic (35)
- # devcards (4)
- # dirac (79)
- # euroclojure (2)
- # immutant (35)
- # om (138)
- # om-next (2)
- # onyx (172)
- # proton (4)
- # protorepl (1)
- # re-frame (36)
- # reagent (34)
- # spacemacs (1)
- # specter (7)
- # untangled (89)
- # yada (2)
I’m trying to use an inner enum from a Java class, but got this exception:
1. Unhandled java.lang.NoClassDefFoundError Could not initialize class com.google.api.ads.common.lib.auth.OfflineCredentials$Api
What happened to cond-let from contrib's cond.clj namespace? Did it move somewhere in core?
Is that something you want to do in production?
in general I think having the :args checked is only really meant for development and testing yes. though obviously you could turn it on in production if you wanted to. If you want to also check the :ret then you need to run
check on the print-name function, which will call print-name with a bunch of randomly generated :x/person's and check that the result is nil
obviously when you call check on a side-effecting function like
print-name you'll get side-effects, so look out 😉
I like when the code is explicit, so I will probably go for the :pre/:post support built in to defn or the explicit calls to s/valid? and s/conform. Thanks for the warning about testing side-effecting functions 🙂
cool cool, I think using :pre and :post is the more intended way of making those checks in production
I come from the Java world with a lot of magic byte-code instrumentation and configuration….after a while you totally lose control! I like the Clojure way where things are very explicit, leading to code that you can follow and understand.
anyone know when the Clojutre videos will be put up?
Trying out spec I wonder how comprehensive is :fn supposed to be? I watched Stu's demo of my-index-of and despite the original claim the verification the :fn invariant is quite weak (much weaker than the happy path scenario it replaces). I can imagine a series of (s/and inv1 inv2 inv3 ... invN) based on a default generator but that seems rather limited. There is a hint how to write an useful generator for testing something like that in the Spec Guide (hello generator) but such a generator can't be used as a default one. Most stronger properties needed custom generators and bind forms ... maybe that is out of Spec scope? I ended up with a standard happy path tests + standard TC tests (+thinking of test.chuck because of clojure.test integration) + very basic spec :fns for most functions. TC tests include a 2nd implementation or round tripping via another fn in the suite (encrypt/decrypt) - that also seems out of spec scope. Note that the code tested is crypto, that is a perfect match for gen. tests. It will only be harder for "normal" code. Thoughts?
@katox: It’s been suggested that s/fdef is best suited for specifying properties of the output type in terms of the input type, that it’s not a good place to specify properties of the fn proper.
@donaldball makes sense - using spec just to describe format of input and output variants and not for actual testing. In that regard I find Stu's descriptions largely confusing 😉
A question about timbre logging, has somebody been able to redirect it to log4j/slf4j? I keep seeing it on the
cider console but not in the logs
Just discovered this: https://github.com/palletops/log-config#logging-from-timbre-to-java-logging
@seancorfield Hi, at World Singles, are you running an abstraction on top of clojure.java.jdbc? And are you using postgres as database?
How do I spec a function that passes its arg to slurp? Something like ::reader-input aboce? I'd like to automatically check its output in test but the gen keeps complaining.
@katox I'm not sure what the long term story for testing functions with side-effects is, but at the moment I think you'll need to stub out the side-effecting function (slurp) with
with-redefs or similar
s/with-gen might be useful
@donaldball: I tried it but I failed to come up with a generator for the snippet above. such-that wasn't satisfied with my proposed solution :)
@sveri We use MySQL and we used to have an abstraction over
java.jdbc but now we tend to use it raw — with HoneySQL when we need to work with composable SQL fragments.
@katox: you may be looking for
s/or instead of
@donaldball good catch, I need to exercise with-gen and with-redefs a bit more
Is there any way to do postgres type casting in a hugsql tuple? Been over the docs a few times and there isn't a simple answer looks like.
@seancorfield Ok, thank you, is it that any abstraction over jdbc does not bring that much value? How would you compare it to JPA? I mean, I know what JPA is and have it used myself, I just wonder why you dont find the need to use a similar abstraction in clojure.
We used to have
find-by-keys in our abstraction layer (as well as hiding the actual DB connection pooling from the rest of our code) but those two functions are in
java.jdbc now — and we’ve moved to
Component for managing state/configuration/etc so we say
(jdbc/query (-> application :database :pooled-db) […]) directly
insert! traffics in hash maps directly, so there’s no "objects" to map to DB columns.
find-by-keys produce sequences of hash maps,
get-by-id produces a hash map. There’s just no mapping to be done there.
When we have complex queries that need to be built, HoneySQL provides the composability we need there.
We do wrap our (Clojure) persistence layer in a thin OOP veneer for our legacy code, but we have a generic class that uses "method missing" hooks to pretend to have accessors for direct properties and for related "objects" using a convention-based approach (`getThing()` looks for
thingid and does a
get-by-id on the
thing table with that as the PK).
Working in Clojure with sequences of maps, we just don’t find a need for anything ORM-like.
(if we know we eagerly need related data from multiple tables, it’s easy to do a
join in the
select instead, especially with HoneySQL)
(and if we want to lazy-load it, then explicitly calling
find-by-keys works fine — if we need caching, we do it explicitly with