Fork me on GitHub
#datomic
<
2018-01-20
>
timgilbert00:01:47

Don’t panic

macrobartfast00:01:37

added [com.datomic/client-pro "0.8.14"] in project.clj and (:require [datomic.client.api :as d]) in core.clj but (def client (d/client cfg)) is producing a java.lang.Exception: namespace 'datomic.client.api' not found

marshall00:01:42

Hmm. I'll have a look at that

marshall00:01:55

That should be working

marshall00:01:23

Might not be till tomorrow. I'm away from my laptop atm

marshall00:01:52

Oh, that one is out of date

marshall00:01:17

The one in getting started should be correct

marshall00:01:26

I'll look at updating both

macrobartfast00:01:05

ok cool... no worries... and thanks for the help so far.

marshall00:01:16

Definitely

macrobartfast01:01:51

It was related to the clojure 1.8 issues mentioned above; switching to clojure 1.9 fixed the datomic.client.api not found issue. I accidentally reverted to 1.8. However, I can't use 1.9 in emacs atm as I haven't resolved my emacs/cider issue, which isn't a datomic issue, certainly.

marshall01:01:42

Ah, glad you got it to work. I'm glad you found that other spot with the old dep I'll fix it this weekend

James Vickers02:01:15

I have a question about entity references (`:db.type/ref`) and history after reading https://docs.datomic.com/on-prem/entities.html#basics.

James Vickers02:01:22

Suppose after the transactions in the example, Entity 42 ("Jane Doe") has :person/lastName changed to "Smith". If you retrieved Entity "John" and traversed to the :person/lastName of the Person entity it refers to (42) will it return "Doe" still? The Entity reference seems to say this, just want to clarify: >Navigation from an entity will always and only reach other entities with that same time basis

marshall02:01:01

@jamesvickers19515 it depends on the basis t of the db value you pass to the query (or entity api call)

marshall02:01:24

If you assert that Jane's last name is now Smith, then you got a new db value (ie with (d/db conn)) and looked at the last name of the person John likes it would be Smith.

marshall02:01:22

If you assert the name change but then ask who John likes with the old db value you'll see the original last name. The db value is immutable

James Vickers03:01:23

So if I wanted to value to still be "Doe" (i.e. not change) for the last name of who John likes, I'd have to track when the reference was associated right? As in keep a basis-t or time along with that reference?

James Vickers04:01:17

I think a better example of what I'm asking about would be an Order that references a Customer entity. If the Customer's address changes later, you still might want to know that at the time the Order was made, the Customer entity had the old address.

James Vickers04:01:53

Oh, maybe an easy way is to use the basis t of the entity itself - entity.db().basisT() - to find the version of Jane with the old last name? Thanks for the replies, I think a REPL session is in order.

dazld12:01:25

I’m trying to write a spec that can cover a function that returns either an integer id, or a tempid. I feel like I’m missing something, perhaps there’s a better way to do it than this…?

dazld12:01:51

(s/def ::entity-id (s/or
                     :raw-id int?
                     :db-id #(instance? datomic.db.DbId %)))

dazld12:01:12

feels weird doing instance checks

dazld12:01:27

using it like this:

dazld12:01:32

(defn find-destination
  “returns an id to either an existing destination or a tempid for insertion”
  [dest]
  {:pre  [(s/valid? ::domain/url dest)]
   :post [(s/valid? ::domain/entity-id %)]}
  (let [db (d/db conn)
        existing (ffirst (d/q ’[:find ?e
                                :in $ ?destination
                                :where
                                [?e :destination/url ?destination]]
                              (d/db conn)
                              dest))]
    (or
      existing
      (d/tempid :db.part/user))))

stuarthalloway13:01:14

@dazld if you are not doing explicit partition management, you should consider using string tempids. This solves your spec problem, and is also compatible with both On-Prem and Cloud

dazld13:01:14

that’s interesting!

dazld13:01:26

so the spec would be str or int

dazld13:01:37

and the tempid can be just any arbitrary string..?

dazld13:01:53

(assuming one needed per tx)

stuarthalloway13:01:30

@dazld yes, str or int. And tempids are needed only when you need to link up related datoms (or manage partitions). Otherwise leave ’em out.

marshall14:01:48

@jamesvickers19515 that's definitely an approach. You can also use an asOf database and/or a history db if you want to see the state of an entity or the whole history of an entity.

marshall14:01:36

In the customer address order example, you could look at the transaction entity for the order to get a basis t to use for a query against an asOf database to ask "what was the customers address at the time this order was placed"

johnj19:01:59

What are the best resources for learning how to model data in datomic?