Fork me on GitHub
#pedestal
<
2017-03-30
>
deg11:03:56

How do I pass an :instant to Datamic through a Vase route?

deg11:03:22

If I pass it as a string to the http query, Datomic sees it as a string and complains. (I'd hoped that :edn-coerce might help, but seems not). If tried passing it as an #inst on the CLJS side, hoping that some magic wrapping would occur, but something (cljs-ajax I assume, though I can't yet see where) converts it to "{}" before it leaves the client.

souenzzo12:03:16

I think you need to customize spec's coerce

mtnygard12:03:58

I can’t speak to the CLJS side of it. But edn-coerce should work if the param contains a string like “#inst{xxxx}”. The tag has to be in the string.

deg13:03:06

@mtnygard - like this? "#inst{Sept 20, 2014}"? Because it doesn't seem to be working.

deg13:03:50

Do I need quote chars inside the braces? (I just tried and failed both with and without; so looking for other issues in my code too)

ddeaguiar13:03:19

@mtnygard what about using transit?

mtnygard13:03:32

Quotes should not be needed. Can you post the contents of your HTTP request here?

mtnygard13:03:59

Sorry, let me amend my last.

mtnygard13:03:13

Quotes are needed around the whole timestamp string, but not inside.

deg13:03:34

{"payload":[{"receipts.purchase/vendor":"Bus","receipts.purchase/uid":"D-1002","receipts.purchase/date":"#inst{1985-04-12T23:20:50.52Z}","receipts.purchase/price":12.34,"receipts.purchase/comment":"Test bus ride","receipts.purchase/currency":"USD","receipts.purchase/category":"Travel"}]}

deg13:03:01

Error is clojure.lang.ExceptionInfo: Interceptor Exception: java.lang.IllegalArgumentException: :db.error/wrong-type-for-attribute Value #inst{1985-04-12T23:20:50.52Z} is not a valid :inst for attribute :receipts.purchase/date

mtnygard13:03:57

I think the inst field should look like this: ”receipts.purchase/date”:”#inst\”1985-04-12T23:20:50.52Z\”"

deg13:03:28

Ah, without braces?

mtnygard13:03:46

but the quotes around the timestamp have to be escaped for json

deg13:03:53

Ah, you were just being meta-syntactic above?

mtnygard13:03:14

@ddeaguiar I’m not sure where we stand with the transit body support. I need to talk with Paul after the conference

mtnygard13:03:37

And also working from memory instead of looking at the doc. 😕

deg13:03:34

Still failing. And I tried both \" (sending a quote across the wire) and \\\" (in case the other side needed it quoted too). I don't want to keep wasting your time on this... can you point me to any doc?

mtnygard13:03:10

just the edn spec i sent before

deg13:03:42

Hmm, so what I'm sending now seems to be valid edn, but I don't know what :edn-coerce expects. So, I think this reduces down to "I need more docs. You need to focus on Clojure West. This is not a critical piece of my toy; I can store dates as strings for now. So, Iet's revisit later". (is there any value in my opening github issues about these minor doc lacks, or will that be too noisy?)

mtnygard13:03:26

from what you’ve shown me, i’d expect it to work. so there may be a bug here. please open an issue, but don’t assume its a doc task.

mtnygard13:03:07

if you feel like getting your hands dirty with something new, it would be a nice place to have a generative test. Something that would generate any data, encode it as json, pass it through an edn-coerced param, and compare the resulting value to the original. “Round trip” tests like that are a nice place to use generative tests.

deg14:03:17

Understood. Not sure how soon I'll have time for this, but I'll try.

deg14:03:11

FWIW, edn itself seems to be more forgiving: => (clojure.edn/read-string "#inst \"1985\"") #inst "1985-01-01T00:00:00.000-00:00"

ddeaguiar14:03:19

I’d shy away from trying to shortcut the content of #inst

ddeaguiar14:03:17

if anything create helpers that make it easier make the edn string

mtnygard14:03:41

You mean the content of the #inst tag, right?

ddeaguiar14:03:55

also that instant implies a level of resolution that is not real. Keep that in mind

deg15:03:43

I found the problem, but not sure how to solve it. Surface problem: I had mistakenly put the :edn-coerce in the wrong place. Real issue: I need it in a #vase/transact, but there is no :params binding there

deg15:03:48

Later: I see from the samples (omnext-todo and petstore-full) that this is solved with an interceptor that coerces the date string. Is this the long-term plan? It feels heavy.

souenzzo15:03:33

Hi, When I do (response-for service :get "/path?foo&bar=123") I expect :query-params {:foo nil :bar "123"}, but pedestal do :query-params {nil "foo" :bar "123} It's Intentional/expected?

ddeaguiar15:03:07

that’s not how you set query-params with response-for

ddeaguiar15:03:13

let me dig up an example

ddeaguiar15:03:15

actually I’m wrong

ddeaguiar15:03:18

this is what I typically use

ddeaguiar15:03:20

(response-for service :get (url-for ::web/foo-bar :query-params {:foo “bar”}))

ddeaguiar15:03:13

which is the same as (response-for service :get /foo-bar-path?foo=bar but I’m pretty sure it encodes things for you

ddeaguiar15:03:16

Now I understand your example @souenzzo

ddeaguiar15:03:50

so I think your example needs to be ”/path?foo=&bar=123”

ddeaguiar15:03:26

but I highly recommend using the url-for helper for creating paths for use with response-for

souenzzo16:03:41

It's not exacly "response-for" problem, thats the nil key problem. I exemplified with response-for because I did not test "in the real world"

ddeaguiar16:03:57

”/path?foo=&bar=123"

ddeaguiar16:03:08

you are missing the = after foo

ddeaguiar16:03:41

so what I pasted is what url-for would emit

ddeaguiar16:03:14

(url-for ::web/foo-bar :query-params {:foo nil :bar 123})

ddeaguiar16:03:50

in tests you do something like this to create a url-for helper

ddeaguiar16:03:34

(def url-for (http.route/url-for-routes web/routes)

ddeaguiar16:03:58

you may need to expand your routes