Fork me on GitHub
#datomic
<
2017-09-11
>
daveliepmann09:09:29

Typo at http://docs.datomic.com/query.html#multiple-inputs : "limit releases to those perfomed by John Lennon." (performed)

tankthinks18:09:13

I have a problem that I believe datomic would solve nicely: I have facts about things I would like to assert and I would like to be able to track those facts over time. The one wrinkle is that I also know the event associated with fact changes, and its timestamp. I want to track the facts over time by this known timestamp, not by the transactors built in time clock. So it looks like I can set :db/txInstant (http://docs.datomic.com/transactions.html#explicit-db-txinstant); however, due to the constraints explained in that link, I am responsible for ordering the events before I transact them.

tankthinks18:09:59

Does this make sense? If so, can someone confirm the last sentence?

marshall18:09:43

@tankthinks That is correct, you can’t assert things in the past (with respect to Datomic’s built-in notion of time). In general, if you have a ‘domain time’ you need to model (i.e. real-world time something happened), it’s best to model it explicitly on your entities with a user-defined attribute

marshall18:09:14

the built-in t in Datomic is Datomic’s notion of time - that is, when did Datomic know about a fact

marshall18:09:10

in some cases you can co-opt t to represent your domain time, but there are a number of reasons that can be problematic - you noticed one with the fact that you can’t assert txInstant values in the past

tankthinks18:09:07

So I can explicitly model "domain time" with an attribute, and as such I get a slightly different "built-in" notion of a database-at-point-in-time

marshall18:09:15

yep exactly

tankthinks18:09:37

Is the performance the same as using the Datomic's built int notion of time?

tankthinks18:09:51

I guess it would be, since txs are first class entities?

marshall18:09:08

it depends a bit - are you interested in ‘time series’ types of queries frequently? i.e. “show me all the changes to this entity or entities” or are you only ever interested in the ‘latest’

marshall18:09:35

and, actually, in either of those ^ cases, you can change some details of your schema to essentially optimize for either

marshall18:09:29

keep in mind, only the log (http://docs.datomic.com/log.html) is ordered by T first; in all the other indexes (avet, aevt, eavt, vaet) t is the least significant sort

tankthinks18:09:57

good to know ^

tankthinks18:09:00

I'm interested in a "graph of things" that changes over time. I'm imagining a time slider UI component that updates the graph as time moves forward and backward.

marshall19:09:17

you could definitely use either approach, but depending on the size of your dataset and how real-time it needs to be, using built-in time may be too limiting

itaied19:09:24

Hello, I'm new to datomic and clojure. I'm trying it out, and starting with the official tutorial I try to create my own data schema. I have created a type/ref isComponent true, but I get the following error: :cognitect.anomalies/message ":db.error/invalid-nested-entity Nested entity is not a component and has no :db/id"

itaied19:09:11

`{:db/ident :node/references :db/valueType :db.type/ref :db/cardinality :db.cardinality/many :db/isComponent true :db/doc "External material and sources"} {:db/ident :reference/title :db/valueType :db.type/string :db/cardinality :db.cardinality/one} {:db/ident :reference/value :db/valueType :db.type/string :db/cardinality :db.cardinality/one}`

itaied19:09:04

and this is the entity that I try to create: {:node/name "Docker" :node/description "Container management tool." :node/references [{:reference/title "Official Docs" :reference/value "https://docs.docker.com/"}]}

itaied19:09:47

What am I doing wrong? It seems like the same as the tutorial...

hmaurer19:09:02

@itaied if your attribute isn’t marked as :db/isComponent, you must set the :db/id explicitly in the transaction

hmaurer19:09:11

in this case it’s throwing because of :node/references