can someone point me to docs explaining the new tempid behavior?

specifically, I'm trying to figure out which values are allowed in :db/id when annotating transactions

oops, after 30 min looking for it, writing here is what made me find it 🙂 http://docs.datomic.com/transactions.html#outline-container-2-1-1

is there a way to reliably catch 'Non-existing look-up ref' exceptions?

(try
  (d/q
    '[:find ?e
      :in $ ?some
      :where [?some :other/attr ?e]]
    db
    [:some/id (d/squuid)])
  (catch Exception e
    (some-> e .getCause .getCause .getMessage (.startsWith "Cannot resolve key"))))

does not seem like the best way 🙂

@stijn Call d/entid beforehand.

thanks @rauh!

Anyone come across the following error before?

java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.lang.RuntimeException: Can't let qualified name: db/id, compiling:(NO_SOURCE_PATH:0:0)
	at datomic.promise$throw_executionexception_if_throwable.invoke(promise.clj:10)
	at datomic.promise$settable_future$reify__6755.deref(promise.clj:54)
	at clojure.core$deref.invokeStatic(core.clj:2228)
	at clojure.core$deref.invoke(core.clj:2214)

someone's trying to do (let [db/id x]). Never seen before

@favila pretty sure it's not me. 🙂

look for macros?

or maybe a map needs some wrapping?

@favila couldn't it be a {:keys [db/id]} destructuring ?

I have a macro for measuring time taken, but removed it to make sure that's not it.

@val_waeselynck that would make sense if it were in a macro.

@val_waeselynck ah, it could be, but on an older clojure

yeah that's what I was thinking

But I'm not doing

(defmacro blah []
  `(let [{:keys [db/id]} (d/transact conn ...)))

search Datomic's source code... oh wait, you can't.

are you transacting?

when you hit this error?

@val_waeselynck 🙂

@favila yep.

could you perchance be doing something like (d/transact conn {:my "map"})

i.e. forgetting to wrap in vector?

(if (seq txes)
     (let [{:keys [db-after]} @(datomic/transact datomic txes)]
       ;; ...
      (datomic/entity datomic db-after (:db/id task)))
    ;; ...
  )

It's something like that with irrelevant bits removed. I'll sniff around the txes to make sure they're valid.

[{:db/id 17592186045447, :task/state :task.state/failed,
   :task/next-run #inst "2017-02-10T17:09:02.353-00:00"}
  [:inc-attr 17592186045447 :task/retries]]

Txes are a vector of a map and a db/fn.

perhaps there's something in the impl of :inc-attr

Oh! That could be it!!

try to invoke it directly

{:db/id #db/id [:db.part/user]
 :db/ident :inc-attr
 :db/fn #db/fn
 {:lang "clojure"
  :params [db lookup-ref attr]
  :code
  (let [{:keys [db/id] :as ent} (d/entity db lookup-ref)]
    [[:db/add id attr (-> ent (get attr 0) inc)]])}}

I have a test for that db/fn mind.

ah there it is

Oh yeah. Parens wrong.

Wait…

@favila I must be missing something. Where's the problem with that db/fn?

looks good to me, unless it runs on an older clojure

1.8.

but it's unlikely the transactor's classpath is being messed with

@jcf does it work when you run the function locally ?

(e.g in a d/with)

(d/invoke db :inc-attr db 17592186045447 :task/retries)

will be more direct

@val_waeselynck I have a couple of tests that use the function, but with an in-memory database.

@jcf and so, do those work ?

Yes 😄

or do they throw the error

ok that narrows the scope

I'm guessing either the transactor runs an older version of Clojure, or there's a problem in the serialization of the function code

Just written this test, and it passes:

(deftest ^:integration t-inc-attr
  (t/with-system [{:keys [datomic]} (test.datomic/new-datomic-system)]
    (let [db (sut/db datomic)]
      (is (= [[:db/add 17592186045447 :task/retries 1]]
             (d/invoke db :inc-attr db 17592186045447 :task/retries))))))

I'll double check the version of Clojure on the transactor, but pretty sure it'll be the same everywhere.

Transactor's running Clojure 1.8 too.

@jcf does it work if you rewrie the function to not use destructuring ?

@val_waeselynck let's see…

Removing the destructuring from the Transactor fixed it.

Strange. We must not be running the version of Clojure I thought, or maybe there's a bug fix we're missing.

Thanks for the help chaps.

@jcf you can write a transaction function which returns the current Clojure version (in an exception)

I mean the one running in the Transactor.

That's one way to do it. I checked the transaction-pom.xml and found Clojure 1.6. I've recommended an upgrade.

@jcf look at the files in lib/ in the txor distribution

unless you are adding to that classpath, those are what you are getting

on the latest transactor, clojure-1.9.0-alpha14 is in use

are you using a very old transactor? or including jars on the transactor's classpath which may overwrite the clojure libs?

What's the right way in Datalog to express that the set of all values bound to a given variable must be equal to the set of all the values bound to another variable?

given set is strict subset of other set?

or the two sets are exactly equal?

@favila: The latter.

Also, what is the most appropriate way to ETL data into ?