=> {:db/id 17592186045443} means :my/attr is installed. => nil means it is not

or a bit fancier: https://gist.github.com/stuarthalloway/2321773

@misha, @bkamphaus aha! It's definitely not there, it returns nil.

Well, {:db/id nil}

@misha: So what reason could it be nil when I definitely installed it in a transact?

@sdegutis how did you install it exactly?

@misha: (d/transact conn txs) where txs included {:db/id (d/tempid :db.part/db), :db/ident :question-template/sort-pos, :db/valueType :db.type/long, :db/cardinality :db.cardinality/one, :db.install/_attribute :db.part/db}

But (d/entity db :question-template/sort-pos) returns {:db/id nil}

there are a variety of reasons this could be the case — that transaction didn’t succeed, that transaction went to a different conn, the conn had the db deleted/recreated prior to following transaction, the order of transaction differs from your expectations, etc.

Is there a way to determine the reason?

As a sanity measure, one thing you could do would be to check the basis-t of the :db-after returned by the map you get from deref-ing the schema transaction vs. the basis-t of the db retrieved from the conn prior to submitting the transaction that fails.

are the transactions on the same peer process, in a way where (for at least debugging) you could guarantee the order? I.e. submit schema transaction, deref future it returns (which will block until transaction succeeds), then follow up? If you can guarantee the order, you could look at the :tx-data returned by the schema transaction.

I'm using Datomic Free with the default H2 thing it uses, and using only one peer process.

I always deref the future it returns immediately after getting it back.

Oh wait, in this specific transact I might not be!

@bkamphaus transact's future will "complete" even if I will not deref it, right? right. what is the "correct" way to transact stuff (in the code, not in repl)? "transact, deref, and see that transaction succeeded/log any errors"?

Hi, guys as far as I remember datomic has a WebUI, it hasn’t?

sort of, yes

@bkamphaus: I think you may have solved it!

@bkamphaus: I've been ignoring the (transact) call's result all this time. Well just now, I finally chose to print it out (without deref'ing it, mind you) and instead of printing it out, it just died, saying: "Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.Error: :transact/bad-data Changing :db/valueType to 22 is not supported for entity 315"

misha: what I should do for getting it? I’m using official ec2 AMI for transactor

@lowl4tency: you mean the web console? http://docs.datomic.com/console.html

https://my.datomic.com/downloads/console

ah, it’s running separetely

$ cat README-CONSOLE.md 
...
If you downloaded Console as a separate download (i.e.: not bundled with Datomic Pro), you will need to install it alongside Datomic:
Run this command from the directory you unzipped Console to:
    bin/install-console path-to-datomic-directory
Switch to your Datomic directory and run:
    bin/console -p 8080 alias transactor-uri-no-db
...

Okay, I don’t need it in this way

CLoudWatch metrics is enough

as a separate download (i.e.: not bundled with Datomic Pro)

@bkamphaus: Yep, I was changing the type of an existing attribute, which isn't allowed in our older version of Datomic. By not deref'ing the schema transact, we were never hearing about that error.

@bkamphaus: Thanks, I owe you a beer.

does it make sense to :db/index true a :db.type/ref?

@bostonaholic: no. refs are all in VAET index already

that's what I thought, thanks @robert-stuttaford

so you can (->> (d/datoms db :vaet your-ref-id :some/attr) seq (map :e)) to get all relations

@sdegutis: probably already something you’ll do from now on, but you should always look at the results of your transact calls

Is there a limit on the number of attributes that d/pull will pull at one time? I’m in a situation where I’m trying to pull 14 attributes, of those 9 exist on this particular entity, but it appears to only return 8 attributes.

@potetm which version of Datomic are you seeing this behavior you’re on? There was a bug w/pull fixed in 0.9.5198 that if I remember correctly had a similar manifestation (showed up w/more than 8 attr): * Fixed bug where the pull API did not always return all explicit reverse references.

That’ll do it I’m running 0.9.5153

The thing that was being dropped was a reverse reference.