Fork me on GitHub
#datomic
<
2016-09-16
>
robert-stuttaford05:09:53

just curious; what'd happen if i attempt to restore a backup that's also currently being backed-up-to?

Ben Kamphaus12:09:37

@robert-stuttaford I believe it should work because you can only restore a backup that is in the set of ts which have been fully backed up in that directory, and segments are immutable so nothing will have been changed by backup process (2).

eggsyntax14:09:17

Bump on my question from yesterday, in the hope that there’s someone around now who can help me understand what’s going on: https://clojurians.slack.com/archives/datomic/p1473974074000693

Ben Kamphaus14:09:09

@eggsyntax I’d write up a gist with a repro case and point it at @marshall or @jaret — as it could be a bug that there’s no error. My estimated reasoning would be that a query like that might work with a reference and since you’re sticking in a Long it might treat it as there not being anything in the reverse index (v/raet).

eggsyntax17:09:00

@marshall or @jaret -- as @bkamphaus suggested above, here's a gist with a minimal complete example of this unexpected behavior in Datomic, where using an underscore as the attribute in a query doesn't return matching datoms. Any insight into what's going on here would be very much appreciated. Thanks! https://gist.github.com/eggsyntax/09aa74cd86f26cffc44c79019216f182

eggsyntax17:09:16

(Or really @whoever, if anyone else has some clarity about this)

jaret17:09:27

@eggsyntax taking a look now

eggsyntax18:09:29

[EDIT: correct outdated comment]

Lambda/Sierra18:09:54

@eggsyntax: I think it's a consequence of indexes. d/q will not do a full scan of the database, which is essentially what you're asking it to do with [?e _ "whatever"] since ?e is unbound.

Lambda/Sierra18:09:19

With the attribute, the query can use the AEVT index.

Lambda/Sierra18:09:38

But there is no index that starts with V for primitive (non-ref) values.

Lambda/Sierra18:09:09

In most cases where your query would imply a full scan, d/q signals an error, e.g. (d/q '[:find ?e :where [?e _ _]] (d/db conn))

marshall18:09:35

@stuartsierra is correct. if you don’t supply e or a to query, but do supply v, it must be a ref type you’re looking for

marshall18:09:02

but since values of reftypes are just numbers (eids) the query engine doesn’t know if you asked for 42 the entity or 42 the value

eggsyntax18:09:53

@stuartsierra @marshall thanks, y’all, much appreciated. That makes sense. Obviously it’s a terrible idea in most cases, but of idle curiosity, is there a way to actually request a full scan?

marshall18:09:10

nope. any query you try to do it with will throw an exception

marshall18:09:21

you can scan manually with the datoms API

Lambda/Sierra18:09:31

The datoms, index-range, and log APIs are all different ways to "scan" the database. But you can't do it with query.

Lambda/Sierra18:09:48

you're welcome

eggsyntax18:09:47

I do think that throwing an error would be a useful behavior there, btw, to help out other folks who encounter this.

eggsyntax19:09:04

But ultimately, for me, it's a good reminder that I still have leftover SQL intuitions to eradicate 😊

magnars20:09:57

A good way to find all datoms in a given transaction? I've been looking at using d/log, but that requires the conn. This should be doable with just the db, right?

Lambda/Sierra20:09:51

@magnars d/log is best, but I think you can also do something like (d/q '[:find ?e ?a ?v ?tx ?add :in $ ?tx :where [?e ?a ?v ?tx ?add] (d/history db) transaction-eid)