A transaction is an entity. Just like any entity, it can be in the E or V slot of any datom

To add an assertion to the current transaction, use the tempid "datomic.tx"

ok, i thought that transactions may be a bit more special than that. thanks

They are special only in that their ids must be in the tx partition, only they may have :db/txInstant assertions (this assertion is what makes it a transaction), and :db/txInstant cannot decrease in value relative to the previous transaction.

that is something i ran into when seeding my DB

It means that values are known for it.

I’ve been reading about rules and required rule bindings and I’m not quite sure I understand the description

Every variable mentioned in a clause is bound (i.e. some set of values was assigned to it) at the end of the clause’s evaluation

but not all may be bound on entering a clause

because some clauses produce the bindings (e.g. by pattern-matching, by unifying other already-bound values, by executing a function and binding the result, etc)

So if I specify that a particular rule argument is required, I should have a where clause (either before or after) which refers to it?

by “required” I assume you mean “must be bound”, i.e. this rule declaration syntax (rule-name [?must ?bind ?these] ?maybe-unbound)?

this says that ?must ?bind and ?these must have values before entering the rule.

Yeah

the rule itself is not allowed to bind them

it can only read/unify on their values

?maybe-unbound may or may not be bound, doesn’t matter

but it will be bound by the time the rule finishes evaluating

Related question: what exactly does unify mean? Again, it’s one of those words used often, yet I dont quite grasp it

:in ?a 
; bound by args: ?a
:where          
; bound: ?a
[?a ?b ?c]
; bound: ?a ?b ?c
[?c ?d]
; bound: ?a ?b ?c ?d
(myrule ?x ?y)
; bound: ?a ?b ?c ?d ?x ?y
[(myfn ?x) ?g]
; bound: ?a ?b ?c ?d ?x ?y ?g

What happens if you first refer to a rule, which has a required variable, and then provide a normal where clause which binds the variable? Does it first ”execute” the latter clause and then ”execute” the rule?

datomic will only sometimes push clauses down not up

so you will just get an error

I wouldn’t rely on clause reordering though. the point of that syntax is to make sure that the rule doesn’t evaluate in an inefficient order

clauses are generally not reordered, so selectivity of the first clause is very important

inside a rule, it can be less predictable than in a :where how the rule was “invoked” in various queries, so someone may have left the vars for the first clauses unbound, causing a potentially large result set.

that syntax is a defense against that

a smarter system would reorder the clause evaluation in the rule based on selectivity or cardinality information, but datomic does not do that

re: unification, imagine that you have a table, and each variable in the query is a column

when a variable is bound, it adds rows to the query with values for that column

the unbound columns remain “blank”

when you “unify” vars, you discard entire rows where a clause is not satisfied for the corresponding vars mentioned

ah, right

oh and thanks a lot for explaining this stuff, I should really read a prolog book or something 🙂

e.g. [?a 1] if ?a is unbound gives you a table of all (unique) ?a where the attribute slot is 1.

[(+ ?a 1) ?b] if ?b is unbound just adds a column ?b with +1 every ?a value for every row

but if it is bound, it discards any rows where ?b is not one more than ?a

the reason I'm reading about this (and asking silly questions) is that earlier today I was looking at some code in review where it had a where clause with a) first a few rules which required some bound variables and b) later a very lax normal clauses which bound those variables. I was a bit confused because I had understood that the variables should be bound before the rule is invoked but apparently the code worked. but later we noticed that with a larger db size it was also quite slow. does this make any sense?

(I should really test this in a repl instead of just pondering about it..)

yep. It sounds like it pushed down the rule, but only as far as needed to get something bound, and you just got lucky that it was enough to satisfy the requirements?

yeah, that would explain the poor performance. It couldn't satisfy the requirements of the rules, until it found the clauses it could bind (returning a huge set of data) which it finally ran through the rules

are you aware of these? https://docs.datomic.com/cloud/best.html#datomic-query

yeah

although reading the datomic documentation sometimes feels a bit like reading clojure spec docs: it all makes sense but first you have to do the work to really understand it yourself 🙂

in any case, thanks a lot for helping me

happy to help

Thank you!

When you say “deleted entities”, do you mean entities which had retractions?

And you just want those entity ids? Or you want to pull from them in some way?

yeah, retractions that i want to pull, which is what i showed in the code