Clojurians Log v2

Why does,

(d/q {:query {:find [?d]
              :where [[_ :some.test/thing ?d]]}
      :args [db]})

(Trying out dev-local)

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

Doh, thanks

:thumbsup:

Docs don’t specify quoting as necessary: https://docs.datomic.com/cloud/query/query-executing.html#querying-a-database

curious - that must be a typo

unless d/q is a macro in the cloud api

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

I'm used to the on-prem datomic

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

using on-prem now?

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. 🙂

xD

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

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

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

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

vs a literal

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

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

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.

it would be fickle as anything though xD

quoted is so much simpler

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

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

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

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

(IMO)

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!

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

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

No I’m afraid not.

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

but yes - there would be all sorts of caveats

it would be terrible xD

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

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

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

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

i dont know if that’s still true

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!!

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

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

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

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

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

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

Yes, but you need to use raw entity ids

[:aref+bref [123 456]]

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

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

Thank you anyway

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