Fork me on GitHub
#datomic
<
2020-09-03
>
henrik09:09:16

Why does,

(d/q {:query {:find [?d]
              :where [[_ :some.test/thing ?d]]}
      :args [db]})
Given me a `java.lang.RuntimeException: "Unable to resolve symbol: ?d in this context"`?

cmdrdats09:09:43

it needs to be quoted so that clojure doesn't try resolve the symbol - '{:find ...}

henrik09:09:20

Doh, thanks

cmdrdats09:09:48

curious - that must be a typo

cmdrdats09:09:17

unless d/q is a macro in the cloud api

henrik09:09:17

Maybe, or I’m missing some subtlety. @U064X3EF3?

cmdrdats09:09:31

I'm used to the on-prem datomic

henrik09:09:52

I’ve only used Cloud, but it was a while back

cmdrdats09:09:02

using on-prem now?

henrik09:09:28

No, I’ve been doing some other stuff for a while (UX, PLing), but I can’t let dev-local just sit there without trying it out. 🙂

favila13:09:51

I think the necessity of quoting is considered “obvious”--a query is a data structure and the symbols in it are not supposed to be resolved eagerly in clojure but used inside the query engine. This can’t be solved with a macro because queries don’t need to be literals

favila13:09:20

that example in the doc you linked to is just a flat-out bug 🙂

cmdrdats14:09:51

@U09R86PA4 surely a macro could technically solve this, since it would be able to walk the inputs and quote the symbols.. it would be ugly, so I way prefer the quoting, but doable?

favila14:09:40

How would a macro look at a query provided as an argument by reference?

favila14:09:44

vs a literal

favila14:09:11

(let [q my-query] (d/q q db))?

cmdrdats14:09:41

I guess it could rewrite the symbols to function calls that would try resolve in local environment or resolve in actual symbols instead.. it would be such a terrible hack

henrik14:09:57

It’s not that far-fetched, if you consider the find clause a kind of declaration. It’s semantically not much weirder than naming parameters in a defn , even though they may not be declared anywhere beforehand.

cmdrdats14:09:53

it would be fickle as anything though xD

cmdrdats14:09:00

quoted is so much simpler

henrik14:09:23

And yet we don’t have to (defn hello '[person-name] …). But hey, it doesn’t matter much. 🙂

favila14:09:30

the difference is that the slot in defn must be a literal

favila14:09:08

you can’t (let [my-arg-vector '[person-name]] (defn hello my-arg-vector,,,))

favila14:09:32

requiring a query literal would be a poor limitation to impose on d/q

cmdrdats14:09:03

(defmacro q [body]
  (println &env))

cmdrdats14:09:08

(let [qr [:find]] (q qr))
{qr #object[clojure.lang.Compiler$LocalBinding 0x694600ab clojure.lang.Compiler$LocalBinding@694600ab]}

cmdrdats14:09:33

but yes - there would be all sorts of caveats

cmdrdats14:09:50

it would be terrible xD

henrik14:09:14

(defmacro d-q [q-map]
  `(d/q ~(assoc q-map :query `(quote ~(:query q-map)))))
😅

henrik09:09:30

(Trying out dev-local)

Stefan14:09:00

Hi! In my new job we’re using Datomic Pro on-prem. We’re now trying to setup continuous integration (CircleCI), but lein deps raises an error that it cannot get datomic from http://my.datomic.com (“not authorized”). What is the “idiomatic” way to use Datomic in continuous integration? Both for testing and for generating release builds? Thanks!

chrisblom14:09:51

do you have a private maven repo that the CI can access? If so you could mirror the dependency there

Stefan14:09:05

No I’m afraid not.

Alex Miller (Clojure team)14:09:26

you do have a private maven repo with your on-prem license

Alex Miller (Clojure team)14:09:23

I'm not sure what's supported in circleci wrt setting up access to it

marshall14:09:26

if you login to your http://my.datomic.com dashboard there are instructions for configuring access to the private maven repo

marshall14:09:52

you’ll need to add user/pw to your leiningen config. older versions required gpg-encrypted key files

marshall14:09:58

i dont know if that’s still true

Stefan14:09:31

Ah that’s good to know, I had no idea. I will have to check with the person who set it up originally then. I think given your info we should be able to get it going, thanks!!

chrisblom14:09:33

CircleCi has a feature to pass secrets as env. vars., you could use that to pass the pw to the build

👍 6
chrisblom14:09:58

if you use leiningen you can call clojure code with unquote, to inject the env var:

:repositories {"my repo"
                 {:url ""
                  :name "repo name"
                  :username "usernamr"
                  :password ~(System/getenv "DATOMIC_PASSWORD")}}
 

Jasper15:09:11

Great, thanks a lot, we got it working like that

Björn Ebbinghaus16:09:08

Is there a way to pull an entity by a composite tuple made out of refs?

favila16:09:04

Yes, but you need to use raw entity ids

favila16:09:54

[:aref+bref [123 456]]

favila16:09:15

(for e.g., assuming that attr is :db/unique and that a and b are both refs)

Björn Ebbinghaus16:09:14

Hm.. 😕 I hoped I could get away with lookup refs instead of eids…

Jake Shelby20:09:21

[Datomic Cloud] I've seen several references in the documentation that says the Application Name, in context of a CF template param, "cannot be changed later" - however, that parameter does show up if I attempt a parameter upgrade in CF. Will bad things happen if I change that? ... Also - what if I really really do need to change the application name? Like in the case of scaling up my system, by breaking the main app out into a new compute group, but needing to still deploy tx fns to the primary group from a separate application name?

3