This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-08
Channels
- # aleph (1)
- # architecture (4)
- # aws (5)
- # beginners (105)
- # boot (1)
- # boot-dev (72)
- # cider (5)
- # clara (15)
- # cljs-dev (51)
- # cljsrn (5)
- # clojure (155)
- # clojure-austin (3)
- # clojure-dusseldorf (2)
- # clojure-finland (1)
- # clojure-greece (37)
- # clojure-italy (17)
- # clojure-nl (1)
- # clojure-russia (6)
- # clojure-spec (23)
- # clojure-uk (6)
- # clojurescript (7)
- # community-development (1)
- # css (10)
- # cursive (15)
- # datomic (45)
- # defnpodcast (1)
- # duct (97)
- # emacs (5)
- # fulcro (46)
- # hoplon (8)
- # instaparse (25)
- # keechma (11)
- # leiningen (16)
- # off-topic (2)
- # onyx (9)
- # planck (2)
- # re-frame (5)
- # reagent (3)
- # reitit (2)
- # ring (6)
- # shadow-cljs (35)
- # spacemacs (9)
- # specter (9)
- # sql (18)
- # uncomplicate (4)
@weavejester when I do this (hawk/watch! [{:paths ["src" "test"] :handler (fn [_ _] (reset))}])
in REPL I got :
java.lang.IllegalStateException: Can't change/establish root binding of: *ns* with set clojure.tools.namespace.repl
@lambder Yes, @myguidingstar reported that as well. It looks like Hawk and tools.namespace don’t like each other for some reason. Perhaps using bound-fn
instead of fn
would work? Or perhaps try a different file watch library?
@weavejester this worked for me:
(hawk/watch! [{:paths ["src" "test"] :handler (fn [_ _] (binding [*ns* (find-ns 'duct.core)] (reset)))}])
Does bound-fn
do anything?
Yes, so:
(hawk/watch! [{:paths ["src" "test"] :handler (bound-fn [_ _] (reset))}])
btw @weavejester any idea what could cause the connection pool to grow by doing (reset) ?
It sounds like it’s not closing the pool correctly. You’re using the Hikaricp key, right? Or just the SQL module?
Ah, yes, I can see by the stacktrace you are using Hikaricp
Does this behaviour occur if you use (reset)
normally?
Ah, sorry, I need to dash. I’ll be back later.
@weavejester manual reset has no problems
whereas the watch style one does : :reloading (firds-mirror4.templates.header firds-mirror4.templates.layout firds-mirror4.templates.login firds-mirror4.templates.index firds-mirror4.handler.core firds-mirror4.handler.example-test)
@weavejester even if I do from repl:
(dotimes [n 50] (do (require '[integrant.repl :refer [clear halt go init prep reset reset-all]]) (reset-all)))
it works fine@weavejester I tried with the clojure-watch.core
lib as well
Okay, I’m briefly back!
Thanks for investigating this, @lambder. I think I need to look into this in more detail. Clearly something in tools.namespace doesn’t like being executed under some circumstances (perhaps in a separate thread?)
I take it you’re not using an editor that has REPL integration, like Emacs, Vim, Atom or Cursive, @lambder?
You might be right, though I don’t know why that would be the case…
If you’re using Cursive, have you considered binding a keyboard shortcut or button to (reset)
?
Pretty sure you can bind one to save and reset, too.
Yes, but it should be untouched by tools.namespace.
I’m curious, too 🙂
I need to head out now, but if you find anything, let me know. I’m more than happy to add a (watch)
function to the dev.clj
file in the Duct template.
Hi @weavejester. Any chance you could help me with something. I'm playing around with your duct guide doc (https://github.com/duct-framework/docs/blob/master/GUIDE.rst) adapting my project slightly as a work through it. I'm on the section to do with creating the users handler under Code > Adding Users
. My table for the email and password is named authors
instead of users
and has two extra columns, firstName
and lastName
. This is my adjusted code for the handler /src/duct_blog/handler/author.clj
:
(ns duct-blog.handler.authors
(:require [ataraxy.response :as response]
[buddy.hashers :as hashers]
[clojure.java.jdbc :as jdbc]
duct.database.sql
[integrant.core :as ig]))
(defprotocol Authors
(create-author [db email password firstName lastName]))
(extend-protocol Authors
duct.database.sql.Boundary
(create-author [{db :spec} email password firstName lastName]
(let [pw-hash (hashers/derive password)
results (jdbc/insert! db :authors {:email email, :password pw-hash, :firstName firstName, :lastName lastName})]
(-> results ffirst val))))
(defmethod ig/init-key ::create [_ {:keys [db]}]
(fn [{[_ email password firstName lastName] :ataraxy/result}]
(let [authorid (create-author db email password firstName lastName)]
[::response/created (str "/authors/" authorid)])))
I am getting the following error when trying to run (go)
: IllegalArgumentException No method in multimethod 'init-key' for dispatch value: :integrant.composite/duct-blog.handler.authors.create_5324 clojure.lang.MultiFn.getFn (MultiFn.java:156)
Any ideas what I'm doing wrong here? I'm sure you're fairly busy with other things at the moment, but I would be immensely greatful if you could help point me in the right direction. Thanks in advance.When you see :integrant-composite/blah
, it’s a composite key, so a vector in the configuration.
Behind the scenes, Integrant converts [:foo :bar]
into something like :integrant.composite/foo+bar
.
And that composite key derives from both :foo
and :bar
. This allows vectors to be treated as normal keywords in the global hierarchy.
So the error message is saying: you have a composite key in your configuration, and none of the values in the vector have multimethods associated with them.
Actually, that’s a good point… I could really write a better error message for that!
Anyway, take a look at your configuration. I suspect that you’ll have misspelled a keyword or something.
So would that mean the issue is stemming from this line? [:post "/authors" {{:keys [email password firstName lastName]} :body-params}]
No, the associated key
It might be something like… [:duct-blog.handler.authors.create]
?
What’s the key associated with the ::create
multimethod?
[:duct-blog.handler.authors/create]
{:db #ig/ref :duct.database/sql}
That ☝️ ?
Ah, yes. I think this might be a bug in Integrant that was recently fixed. I don’t think Integrant was loading namespaces based on their parents.
So the easiest way to fix it is to remove the vector around the key
:duct-blog.handler.authors/create
{:db #ig/ref :duct.database/sql}
Integrant will look for namespaces matching the key, but I believe that there was a problem in the previous Integrant version that made that not work for composite keys.
Cool, that got me a little further
Thank you
So because you’ve made the key into a composite key by wrapping it in a vector, Integrant wasn’t loading the duct-blog.handler.authors
namespace.
Got a different error now, but I'll try figure that one out before asking for more help 🙂
The latest Integrant should work in either case.
Cool. Thanks for the explanation 👍 Makes sense now
Let me know if you get stuck on your next problem, @yogidevbear.
@weavejester I think my issue relates to this: https://github.com/duct-framework/migrator.ragtime/issues/1
I'm getting the exact same error message and it happens when trying to run (go)
Try dropping your dev database and recreating, then. Or fix it manually.
Okay, will give that a try
Unfortunately I don’t think there’s a lot we can do about errors like that, except perhaps by using some sort of migration DSL, maybe? If the dev can execute arbitrary SQL statements, then there’s always a chance of the database getting into a bad state.
Do I simply delete the dev.sqlite file?
Guessing not 🙂 Deleted the file and re-ran (dev)
and (go)
and ended up at the same state
Hm, that should have worked. What’s the error?
user=> (dev)
:loaded
dev=> (go)
:duct.migrator.ragtime/applying :duct-blog.migration/create-authors#d0106059
:duct.migrator.ragtime/applying :duct-blog.migration/create-categories#8a201519
:duct.migrator.ragtime/applying :duct-blog.migration/create-posts#0a8584f9
:duct.migrator.ragtime/applying :duct-blog.migration/create-category-post-groups#97ceabe1
IllegalArgumentException No method in multimethod 'init-key' for dispatch value: :duct-blog.handler.authors/create clojure.lang.MultiFn.getFn (MultiFn.java:156)
Oh wait
Different error
Ah, yep, so the db migrates okay, but we’re back to not finding the dispatch value…
Hm, where is the duct-blog.handler.authors
namespace in your project?
src/duct_blog/handler/author.clj
Should that be authors.clj
?
Yes 🙂
There we go 😆
The joys of keyboard and chair
Thank you 👍
No problem. I wonder if that sort of error could be caught by a linter.
Might be a good idea, although more tools... more complexity maybe?
I think Eastwood (https://github.com/jonase/eastwood) lints namespace errors.
Though I don’t think it’ll help you if the ns definition is correct but the keyword in the config file is wrong.