This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-08
Channels
- # aleph (4)
- # beginners (5)
- # cljs-dev (21)
- # clojure (155)
- # clojure-dev (3)
- # clojure-italy (10)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-russia (5)
- # clojure-spec (42)
- # clojure-uk (11)
- # clojurescript (170)
- # code-art (1)
- # component (3)
- # core-async (28)
- # cursive (70)
- # data-science (3)
- # datascript (1)
- # datomic (28)
- # emacs (6)
- # gorilla (1)
- # graphql (2)
- # jobs (1)
- # lein-figwheel (4)
- # lumo (7)
- # off-topic (13)
- # om (63)
- # parinfer (66)
- # planck (1)
- # re-frame (22)
- # reagent (2)
- # ring-swagger (53)
- # rum (3)
- # sql (13)
- # test-check (2)
- # unrepl (48)
- # vim (8)
- # yada (33)
I've gotten it multiple times from multiple people at cognitect. But I suspect they would view 10 as ok. I'm thinking more on the order of hundreds or more.
Question: say I model a linked list in Datomic through an attribute :foo/parent
, pointing to the immediate parent of an entry in the list. What would be the most efficient way to fetch the N elements in the list starting from some element X? It seems that I could just follow the :foo/parent
attributes as if the list was in-memory, and the AEVT index will ensure that storage isn’t hit very often as it will get the data in segments of ~1000 attributes. Is that correct?
Although if I have a lot of such lists, the probability of two consecutive entries :foo/parent
attribute being in the same segment will probably be quite low
Actually this might not be as bad as I thought. Even if in the worst case scenario (e.g. cold cache) fetching 50 entries in a list requires 50 roundtrips to storage, once the cache is hot storage shouldn’t be hit nearly as much
@favila I did not know it was possible to run multiple databases on one transactor? That sounds pretty awesome
If I transact tx-data and I don’t know if that tx-data actually changes any values - acknowledging that obviously it updates the time at which the values were asserted - what would be the way to diff :db-before and :db-after? for instance, say I attempt to add an index to attribute that already has one, I would want to look at a diff of before and after and see no changes.
@uwo any reason not to just look at the :tx-data in the transaction result map?
@solussd won’t that contain the datom that “updates” the value to the same thing as well?
@uwo it’ll contain a new transaction datom, but if nothing actually changed, that’ll be the only thing there.
Say, I'm trying to get every tx that touched a certain entity out of datomic (for an auditing tool, performance is not currently an issue). So for a given eid I want to find transactions where it was either in the e
or v
position in the datom.
This is what I've got right now, but it's giving me ()
and I'm pretty sure my logic is wrong:
(d/q '[:find [?tx ...]
:in $ ?log ?target
:where
[(tx-ids ?log nil nil) [?tx ...]]
[(tx-data ?log ?tx) [[?e _ ?v]]]
(or-join [?target ?v ?e]
[(= ?target ?v)]
[(= ?target ?e)])]
db log eid)
(In reality I'm trying to just get transactions with a certain bit of reified data on them, but I need to get this bit working first)
Not really sure how to use the ?e and ?v values I get back from (tx-data)
in further datalog
I also tried it this way with the same results:
(d/q '[:find [?tx ...]
:in $ ?log ?target
:where
[(tx-ids ?log nil nil) [?tx ...]]
[(tx-data ?log ?tx) [[?e _ ?v]]]
(or-join [?target]
[?target _ ?v]
[?e _ ?target])]
db log eid)
Aha! Got what I was looking for via this:
(d/q '[:find [?tx ...]
:in $ ?target
:where
(or [?target _ _ ?tx]
[_ _ ?target ?tx])]
(d/history db) eid)
Be careful, there is no guarantee that your second clause will match entity ids only. You should guard the attribute valuetype, or use d/datoms :eavt and :vaet directly
Belatedly following up, but this would just be guarding against the possibility that I happen to have an int whose value is the same as the EID I'm passing in, right? Otherwise I'm thinking the ?target
would restrict the value adequately
sometimes tempids get represented like {:part :db.part/user, :idx -1000944}
when nested inside a map. trying to figure it why :thinking_face:
also, i need a reliable way to detect if something is a tempid, and this sneaks past my checker
@devth could you give an example? d/tempid
will return something of that form:
wef-backend.core=> (d/tempid :db.part/user)
#datomic.db.DbId {:idx -1001185 :part :db.part/user}
Be careful, there is no guarantee that your second clause will match entity ids only. You should guard the attribute valuetype, or use d/datoms :eavt and :vaet directly
Belatedly following up, but this would just be guarding against the possibility that I happen to have an int whose value is the same as the EID I'm passing in, right? Otherwise I'm thinking the ?target
would restrict the value adequately