juxt

onetom 2020-02-19T04:33:26.030100Z

i just tried to integrate it into a test suite as a before-each hook and im not sure if it's a good idea to make it recursive, because of that implicit clip/start. that would mean u can only start systems using this with construct, but intuitively i wrote the following code first:

(declare ^:dynamic q)

(use-fixtures
  :each (fn [test-case]
          (sys/with [sys {:components (merge sys/datomic sys/graphql)}
                     {:keys [graphql/schema-fn]} sys
                     schema (schema-fn)]
            (binding [q (fn [query] (gql/execute schema query {} {}))]
              (test-case)))))

onetom 2020-02-19T04:37:16.030300Z

which wouldn't work, even if with would have handled multiple bindings... so currently i have this instead:

(use-fixtures
  :each (fn [test-case]
          (sys/with [sys {:components (merge sys/datomic sys/graphql)}]
            (let [{:keys [graphql/schema-fn]} sys
                  schema (schema-fn)]
              (binding [q (fn [query] (gql/execute schema query {} {}))]
                (test-case))))))
which i think is not too bad... it raises the question though, how would u expose an api for tests, which are specialised for or tied to a specific system instance? it can help immensely to write concise tests, eg:
(deftest query-test
  (expect {:data {:txns [{:id "x" :tags ["tag-1"]}]}}
          (q "{ txns { id tags } }")))

onetom 2020-02-19T07:03:05.030500Z

For the record, before I started using clip, I had a macro, like this:

(defmacro in-tmp-db [& body]
  `(let [db-uri# (str (gensym "datomic:<mem://test>-"))]
     (d/create-database db-uri#)
     (let [~'conn (d/connect db-uri#)
           ~'tx! (fn [&amp; ~'args] (apply d/transact ~'conn ~'args))
           ~'db! (fn [] (d/db ~'conn))
           ~'entity (fn [&amp; ~'args] (apply d/entity (~'db!) ~'args))
           ~'entid (fn [&amp; ~'args] (apply d/entid (~'db!) ~'args))
           ~'pull (fn [&amp; ~'args] (apply d/pull (~'db!) ~'args))]
       (try
         @(~'tx! (datomic/schema))
         ~@body
         (finally
           (d/release ~'conn)
           (d/delete-database db-uri#))))))
so my tests looked something like this:
(deftest some-test
  (expecting "something"
    (in-tmp-db
      (some.datomic/transaction! conn {:entity "map"})
      (expect #{"data-1" "data-2"} (some.datomic/query (db!) [:lookup "ref"])))))

dominicm 2020-02-19T08:34:56.030700Z

I don't understand the question, sorry

p-himik 2020-02-19T08:44:28.031Z

Seems like the https://juxt.pro/radar.html page is broken.

2šŸ‘
Lu 2020-02-19T08:49:44.032Z

Thanks for flagging! We are on the process of killing/reworking a few pages :)

grounded_sage 2020-02-19T10:27:06.033700Z

Iā€™m having a bit of trouble finding a parse function in juxt/tick I have a date string like this. ā€œ`20091127"` which I want to convert into a proper date.

grounded_sage 2020-02-19T10:34:26.034200Z

Looking for the equivalent of this from clj-time

(f/parse custom-formatter "20100311")
=&gt; #&lt;DateTime 2010-03-11T00:00:00.000Z&gt;

tmt 2020-02-19T11:02:22.041Z

Hey there, internally we use an interface IParseable which just uses a regex to split up the string and pass the ints to the relevant constructors (https://github.com/juxt/tick/blob/1e14333e3ce142dd3eebb0cca9449a980a924f1e/src/tick/core.cljc#L117). We don't provide a method to create a IParseable instance from a string, so i think the easiest way to read that string in is splice in dashes at the relevant points and then just pass it to tick/parse. There's a parser in there yy yy-mm-dd which is basically what you need.