Fork me on GitHub
#datomic
<
2017-08-08
>
favila00:08:19

At least ten. Many have low write volume

favila00:08:30

Where did you get advice to use fewer dbs?

sparkofreason04:08:44

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.

hmaurer15:08:35

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?

hmaurer15:08:09

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

hmaurer15:08:18

Does anyone have an approach to recommend?

hmaurer15:08:02

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

hmaurer15:08:07

as far as I understand

mitchelkuijpers15:08:52

@favila I did not know it was possible to run multiple databases on one transactor? That sounds pretty awesome

uwo18:08:44

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.

Joe R. Smith19:08:49

@uwo any reason not to just look at the :tx-data in the transaction result map?

uwo19:08:55

@solussd won’t that contain the datom that “updates” the value to the same thing as well?

Joe R. Smith19:08:40

@uwo it’ll contain a new transaction datom, but if nothing actually changed, that’ll be the only thing there.

timgilbert19:08:06

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)

timgilbert19:08:11

(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)

timgilbert19:08:36

Not really sure how to use the ?e and ?v values I get back from (tx-data) in further datalog

timgilbert19:08:02

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)

timgilbert20:08:28

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)

favila01:08:05

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

timgilbert15:08:38

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

devth20:08:31

sometimes tempids get represented like {:part :db.part/user, :idx -1000944} when nested inside a map. trying to figure it why :thinking_face:

devth20:08:50

also, i need a reliable way to detect if something is a tempid, and this sneaks past my checker

hmaurer21:08:40

@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}

devth21:08:18

i'm not sure exactly - maybe it's just an artifact of pretty printing

devth21:08:55

looks like that is the case. (pprint (d/tempid :db.part/user))

devth21:08:09

this outputs a string like {:part :db.part/user, :idx -1000050}

favila01:08:05

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

timgilbert15:08:38

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