Fork me on GitHub
#duct
<
2017-12-08
>
weavejester00:12:44

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

lovuikeng05:12:29

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)

lovuikeng05:12:34

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

snichme06:12:55

#duct/resource worked like a charm!

snichme06:12:53

Copied most of the lines from the guide

snichme06:12:54

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

snichme06:12:59

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

lovuikeng07:12:04

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

lovuikeng07:12:14

thank you anyway šŸ™‚

lovuikeng07:12:37

maybe some sort of deps issue

snichme07:12:43

did you try a lein clean?

snichme07:12:33

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

lovuikeng07:12:04

did too lein clean

snichme07:12:34

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

snichme07:12:51

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

lovuikeng08:12:47

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 šŸ™‚

snichme08:12:55

which lib?

snichme08:12:30

itā€™s always been named duct/handler.sql

lovuikeng08:12:55

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

lovuikeng08:12:15

all well and dandy now, thank you

lovuikeng08:12:23

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

lovuikeng08:12:34

anyway, it's working fine now

weavejester12:12:31

Yes, sorry, that was a typo in the guide. Iā€™m still writing it šŸ™‚

rickmoynihan16:12:27

@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?

weavejester16:12:41

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

rickmoynihan16:12:54

yeah of course - no rush šŸ™‚

rickmoynihan16:12:34

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"}

weavejester17:12:34

Because #int isnā€™t a good data reader.

rickmoynihan17:12:44

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.

rickmoynihan17:12:52

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

weavejester17:12:26

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

weavejester17:12:53

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

weavejester17:12:16

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

weavejester17:12:47

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

weavejester17:12:48

Iā€™ve been considering doing something like:

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

rickmoynihan17:12:12

is it not a pragmatic abuse? šŸ˜‰

rickmoynihan17:12:30

aero does it šŸ™‚

rickmoynihan17:12:34

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.

weavejester17:12:27

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?

weavejester17:12:50

e.g.

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

rickmoynihan17:12:28

hahaha lolā€¦ yesā€¦ weā€™ve spoken before about preventing duct sliding too far that way šŸ™‚

weavejester17:12:30

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

rickmoynihan17:12:33

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! šŸ™‚

rickmoynihan17:12:27

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

weavejester17:12:45

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

rickmoynihan17:12:25

generally noā€¦ but it can be; and spec can conform values too.

rickmoynihan17:12:35

I do agree with that point thoughā€¦ Iā€™m really just saying there is more to data than maps and keywords.

weavejester17:12:41

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.

rickmoynihan17:12:25

but Iā€™m pretty sure duct is already turing complete šŸ˜•

weavejester17:12:26

I donā€™t think code is bad per se, but it is opaque.

weavejester17:12:48

What do you mean?

rickmoynihan17:12:42

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.

weavejester17:12:12

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

rickmoynihan17:12:15

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.

weavejester17:12:46

Most Clojure code is valid edn šŸ™‚

weavejester17:12:24

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ā€

weavejester17:12:48

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

rickmoynihan17:12:49

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.

rickmoynihan17:12:30

I should really let you assign the actual percentage values šŸ˜‰

rickmoynihan17:12:21

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

rickmoynihan17:12:47

sorry got to rush for my trainā€¦ could be 20cm of snow by the time I get home šŸ˜•

weavejester17:12:21

Good luck on your journey back!