Don’t panic

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

just trying to follow along at https://docs.datomic.com/on-prem/getting-started/connect-to-a-database.html

Hmm. I'll have a look at that

That should be working

thanks!

looks like there might be a different dep at https://docs.datomic.com/on-prem/project-setup.html

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

Oh, that one is out of date

The one in getting started should be correct

I'll look at updating both

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

Definitely

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.

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

cool cool

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

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

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

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.

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

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?

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.

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.

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…?

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

feels weird doing instance checks

using it like this:

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

@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

that’s interesting!

so the spec would be str or int

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

(assuming one needed per tx)

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

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

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"

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