@snichme You might be able to do {:body #duct/resource "index"}

following the new todo CRUD docs, adding the create-entries with migration results in No implementation of method exception :duct.migrator/ragtime {:migrations [#ig/ref :todo.migration/create-entries]} [:duct.migrator.ragtime/sql :todo.migration/create-entries] {:up ["CREATE TABLE entries (id INTEGER PRIMARY KEY, description TEXT)"] :down ["DROP TABLE entries"]} dev=> (go) :duct.migrator.ragtime/rolling-back :todo.migration/create-entries#ff5e14f4 IllegalArgumentException No implementation of method: :run-down! of protocol: #' ragtime.protocols/Migration found for class: nil clojure.core/-cache-protocol-f n (core_deftype.clj:583)

anyone got a working copy mind sharing the project.clj and config.edn?

#duct/resource worked like a charm!

Copied most of the lines from the guide

Only thing that I hade to add is a dependency [duct/handler.sql "0.3.1"] to project.clj, ping @weavejester

Have you tried lein clean before starting it? I have had that error before (some time ago) but after getting fresh new versions it went away

odd, I did exactly the same, still seeing the same exception after applying your snippet, @snichme

thank you anyway 🙂

maybe some sort of deps issue

did you try a lein clean?

och check versions with lein deps :tree and then I can compare it with mine

did too lein clean

Dont know if it matters but I got [org.clojure/java.jdbc "0.5.8"] and as a dep for duct/handler.sql and not under duct/module.sql. But dont know if that might be the issue

Hmm, had another project with the same project.clj that you got (without the sql handler) and that worked. So really no idea, sorry

thank you my friend, it's ok, after deleting my local repo of duct lib, appeared that I'm having proxy issue downloading duct/handler "0.3.1"... not sure what happened, anyway at least it's getting clear. appreciate your help 🙂

strange, @snichme the lib got renamed to handler.sql https://clojars.org/repo/duct/handler.sql/0.3.1/

which lib?

it’s always been named duct/handler.sql

uh... typo in docs ... :dependencies [[org.clojure/clojure "1.9.0-RC1"] [duct/core "0.6.1"] [duct/handler "0.3.1"]

ahh

all well and dandy now, thank you

I had to in fact recreate new todo project to make it work... was having caching problem with duct.migrator.ragtime/rollback from older config, updating config, reset, even clean, won't help... very strange

anyway, it's working fine now

Great

Yes, sorry, that was a typo in the guide. I’m still writing it 🙂

@weavejester: Hey… 🙂 1. Firstly great speaking to you at clojurex! Thanks for that it was great speaking to you… 2. Did you post the duct sample app you were using in your talk anywhere?

@rickmoynihan I will do, but I want to finish off the associated guide first.

yeah of course - no rush 🙂

and finally… a question about #duct/env… Is there a reason it needs to support coercion? i.e. why have another way to do it and write this {:port #duct/env ["PORT" Int :or 3000]}? When you can do this? {:port #int #duct/env "PORT"}

Because #int isn’t a good data reader.

obviously not the end of the world… but we already have some readers defined for things that work elsewhere e.g. we have a #uri to represent a URI type in our config.

can you explain? I know reader literals can sometimes compose badly

Data readers are designed to read tagged data. A #uri tag is fine, because it adds specificity to strings.

But edn already supports integers, so why write #int "1" when you can write 1?

Obviously in this case we want to perform a coercion, but that’s using data readers for something they weren’t designed for.

Even #duct/env "PORT" is kinda an abuse.

I’ve been considering doing something like:

{[:duct/env :app.const/port] {:var "PORT", :coerce Int, :default 3000}}

is it not a pragmatic abuse? 😉

aero does it 🙂

I think I see what you’re driving at though… because it is kinda weird… i.e. to use something defined at read time to coerce a runtime value.

I think it’s the start of a slippery slope. It might be useful, but beyond a point you have to ask oneself why not just have a Clojure file instead of edn?

e.g.

{:port (Integer. (System/env "PORT"))}

hahaha lol… yes… we’ve spoken before about preventing duct sliding too far that way 🙂

Obviously there’s a line somewhere, but the more we abuse data readers, the more uncomfortably close we get to crossing it.

well I’ve been thinking a bit about this whole thing… and TBH I’ve never entirely bought into the whole lets “data all the things” craze that’s swept clojure ecosystem over the last few years. In some sense it’s a little strange, as clojure code is just data too… And things like lists and symbols are part of edn too… which is why at first I thought integrants use of namespaced keywords to identify functions was strange, when it might be more natural to use namespaced symbols to do the same thing. Though obviously symbols can’t be used in hierarchies etc so good call on that one as hierarchies are great! 🙂

anyway this isn’t a criticism as the data craze has led to some great things and less emphasis on macros etc.

Clojure code is data, but it’s not data that’s structured in a way that allows for straightforward querying.

generally no… but it can be; and spec can conform values too.

I do agree with that point though… I’m really just saying there is more to data than maps and keywords.

e.g. I think it’s very hard to reason about Turing-complete code. For example, try writing a function that uses static analysis to find all the ports an arbitrary Clojure program will listen on.

agreed

but I’m pretty sure duct is already turing complete 😕

I don’t think code is bad per se, but it is opaque.

What do you mean?

it’s really more a technicality than in practice… so really not the end of the world; in the same way that the java type system being TC isn’t in practice… But if you were smart enough you could probably compute anything with appropriate use of merge with metadata for conditionals and #duct/include/resource (I forget) for self reference / loops.

Yeah, :duct.core/include is a possible source of recursion, but I intend to replace that. The metadata merging I’m reconsidering as well.

Anyway… on the whole clojure vs data thing I think it’s interesting that the example you posted is actually valid edn: (clojure.edn/read-string "{:port (Integer. (System/env \"PORT\"))}") I’m not suggesting the above is a good config file format; just that there are more types to EDN data than most people think.

Most Clojure code is valid edn 🙂

exactly

With Clojure it’s just a question of not “we should write this with data”, since everything is data, but more “we should write this as data with these particular properties”

Duct/Integrant want data that’s readable and query-able, for example.

anyway the general realisation I had was that duct/integrant is 50% about moving it to readable data — as you say… but 50% about exploding the require tree.

I should really let you assign the actual percentage values 😉

but for me the move to config is at least in part about removing restrictions over the linear single pass parse process in clojure

sorry got to rush for my train… could be 20cm of snow by the time I get home 😕

Good luck on your journey back!