This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-16
Channels
- # alda (1)
- # aws-lambda (1)
- # bangalore-clj (1)
- # beginners (70)
- # boot (24)
- # cider (1)
- # cljs-dev (167)
- # cljsjs (8)
- # cljsrn (17)
- # clojure (224)
- # clojure-android (7)
- # clojure-austin (8)
- # clojure-russia (17)
- # clojure-spec (120)
- # clojure-uk (46)
- # clojurescript (68)
- # community-development (198)
- # conf-proposals (1)
- # core-async (7)
- # cursive (6)
- # datomic (27)
- # dirac (19)
- # events (9)
- # hoplon (2)
- # jobs (1)
- # luminus (9)
- # off-topic (1)
- # om (281)
- # om-next (5)
- # onyx (50)
- # pedestal (1)
- # re-frame (19)
- # reagent (11)
- # ring-swagger (14)
- # slack-help (2)
- # spacemacs (1)
- # untangled (72)
- # yada (30)
just curious; what'd happen if i attempt to restore a backup that's also currently being backed-up-to?
@robert-stuttaford I believe it should work because you can only restore a backup that is in the set of t
s which have been fully backed up in that directory, and segments are immutable so nothing will have been changed by backup process (2).
rad, thanks
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
@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).
@bkamphaus OK, thanks.
@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
@eggsyntax taking a look now
@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.
With the attribute, the query can use the AEVT index.
But there is no index that starts with V for primitive (non-ref) values.
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))
@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
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
@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?
The datoms
, index-range
, and log
APIs are all different ways to "scan" the database. But you can't do it with query.
you're welcome
I do think that throwing an error would be a useful behavior there, btw, to help out other folks who encounter this.
But ultimately, for me, it's a good reminder that I still have leftover SQL intuitions to eradicate 😊
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?
@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)