Fork me on GitHub
#datomic
<
2017-12-06
>
Oliver George00:12:16

(Second use case is required fields. Feels like something a (s/keys :req [...]) might cover nicely. Again, I'd love confirmation of common/recommended approaches).

steveb8n03:12:11

@olivergeorge this post is an excellent pattern which I have used : http://cjohansen.no/referentially-transparent-crud/

steveb8n03:12:00

it allows you to run all mutations through a single fn and this can call the db via a standard set of transaction fns so that all constraints are always checked

steveb8n03:12:44

I think that Datomic Cloud will also have enhanced txn fn support, Stu hinted at that in his talk

Oliver George05:12:13

Thanks I’ll check it out

boldaslove15612:12:47

If I have an eid of :db/txInstant , how do I get the transacted data?

souenzzo12:12:52

(d/q '[:find ?e ?a ?v ?tx ?op 
          :in $ ?tx
          :where 
          [?i :db/ident ?a]
          [?e ?i ?v ?tx ?op]]
        (d/history (d/db conn)) tx)
You may like to translate ?v to ident in case of enums.

souenzzo12:12:56

you can also use [(if ?op :db/add :db/retract) ?x] to create a "tx-data-like" result.

boldaslove15612:12:46

Thanks! I was missing the first part of the clause and kept getting "full scan" error

Ben Kamphaus14:12:39

tx-data with the Log API in query will use the most efficient index for this http://docs.datomic.com/log.html#log-in-query — the query above is basically still a scan - it just limits the A position of the datoms to attributes. You can use any t oriented APIs also with datomic.api/tx->t

kenbier19:12:44

If i have an entities A and B, and A->B. If i edit b, i want to be able to query all transactions that include A to include anytime B changed. Is there some good conventions on how to do that?

kenbier19:12:23

I was thinking about just upserting the unique id of A in any transaction that edits B. is there a better approach than this?

kenbier19:12:17

although i believe datomic doesn’t record a transaction if the value doesn’t change, so perhaps that won’t work.

kenbier19:12:36

something along the lines of ’“touching” A whenever I edit B perhaps?

marshall19:12:40

you may be able to use transaction metadata - either put an attribute on the transaction entity that indicates what ‘parent’ entity(s) it affects, or go the other way and have an attribute on your entity of interest that references the transaction entity ID itself and is updated whenever that entity chain is ‘touched’

marshall19:12:53

depends a bit on what your query pattern / use case is

kenbier22:12:45

@marshall Perhaps I should describe the data model first. Imagine a simple hash (string->string). I could change each value in the hash, add new key-value pairs to the hash, or delete keys the hash. I want to look at the history of this hash over time, as well as the history of an individual key in the hash. In datomic, I have modeled the hash as A, using a many ref to a bunch of pairs (entity B). B naturally has attributes key and value, each of type string. Its easy to see the history of each key value pair, but getting the history of the entire hash is more expensive the way I am doing it. Hash historical view: {“foo” “bar” “c++” “awesome”} => {“foo” “bar” “c++” “sucks”} => {“foo” “bar” “c++” “meh” “clojure” “awesome”} (notice the double edit in the last change, thats allowed) Key historical view: “c++” => [“awesome” “sucks” “meh”]

kenbier22:12:25

I wonder if there is a better way to do this than I am doing currently.

kenbier22:12:33

At the moment I am using the query API to get all txns ids in which a B (pair) changed that was owned by A. Then I can do a pull on A, at the database value during that time. But that means a database query for every transaction id, and there could be many (perhaps I could limit to 10 at a time). Now the schema is not set in stone, perhaps my model is poor given my use case. However I would like to preserve the time view of both an individual key value pair as well as enabling easy time view of the entire hash.

kenbier01:12:13

@marshall i can move this to a google groups topic if you prefer.

kenbier01:12:21

its getting a bit lengthy 🙂

marshall19:12:34

if you re-assert the same value (i.e. your unique id) you won’t get that datom - you’ll still have a transaction with an ID and a txInstant, but Datomic removes redundant datoms

kenbier22:12:45

@marshall Perhaps I should describe the data model first. Imagine a simple hash (string->string). I could change each value in the hash, add new key-value pairs to the hash, or delete keys the hash. I want to look at the history of this hash over time, as well as the history of an individual key in the hash. In datomic, I have modeled the hash as A, using a many ref to a bunch of pairs (entity B). B naturally has attributes key and value, each of type string. Its easy to see the history of each key value pair, but getting the history of the entire hash is more expensive the way I am doing it. Hash historical view: {“foo” “bar” “c++” “awesome”} => {“foo” “bar” “c++” “sucks”} => {“foo” “bar” “c++” “meh” “clojure” “awesome”} (notice the double edit in the last change, thats allowed) Key historical view: “c++” => [“awesome” “sucks” “meh”]

kenbier22:12:33

At the moment I am using the query API to get all txns ids in which a B (pair) changed that was owned by A. Then I can do a pull on A, at the database value during that time. But that means a database query for every transaction id, and there could be many (perhaps I could limit to 10 at a time). Now the schema is not set in stone, perhaps my model is poor given my use case. However I would like to preserve the time view of both an individual key value pair as well as enabling easy time view of the entire hash.

Zach Curry23:12:28

diatomic.client appears to expose ring.adapters.jetty to an incompatible version of jetty. Am I missing something or am I the only using using datomic.client? I’m definitely not the only one using ring and jetty :thinking_face:

kenbier01:12:13

@marshall i can move this to a google groups topic if you prefer.