datomic 2021-10-12 | Slack Archive

stuarthalloway14:10:18

Hi @danvingo! We have certainly considered adding a query planner to Datomic, and might do so in the future. A good query planner has an obvious benefit: It makes queries run faster without needing any help from the user. OTOH, as @oscarlinusericsson points out, query planners can sometimes cause surprising and slow results. If there is no user control, this can be catastrophic. If the query planner includes user knobs, the "obvious benefit" becomes less obvious.

dvingo16:10:37

Thanks @U072WS7PE ! I appreciate you taking the time to reply 🙂

dvingo16:10:03

Perhaps instead of a "knob" there could be just a "button" (on and off) that can be passed as an option to q

stuarthalloway16:10:41

Agreed. Related: we are certainly interested in specific performance problems as folks encounter them.

Ivar Refsdal18:10:42

Re performance: Here is a gist reproducing an OOM with a simple query: https://gist.github.com/ivarref/0d3d34eeeffbc4625d6120727368e405 I am already in contact with Jaret B on this one (via support)

Tobias Sjögren15:10:57

Does anyone know when the concept of immutability within databases arose and who is the originator of this idea?

Alex Miller (Clojure team)15:10:47

isn't immutability the obvious choice? who came up with the crazy idea of mutating data in place?

Tobias Sjögren15:10:00

Agree. Not me.

DenisMc15:10:16

Hi, I’m struggling to get my head around a basic use-case for Datomic (years of relational thinking are taking some time to unwind!). To boil the problem down to its simplest, consider a datomic schema as follows:

{:db/ident :foo/id
   :db/valueType :db.type/uuid
   :db/unique :db.unique/identity
   :db/cardinality :db.cardinality/one}

{:db/ident :foo/foo-description
   :db/valueType :db.type/string
   :db/cardinality :db.cardinality/one}
  {:db/ident :foo/bars
   :db/valueType :db.type/ref
   :db/cardinality :db.cardinality/many
   :db/isComponent true}
  {:db/ident :bar/id
   :db/valueType :db.type/uuid
   :db/unique :db.unique/identity
   :db/cardinality :db.cardinality/one
   }
  {:db/ident :bar/bar-description
   :db/valueType :db.type/string
   :db/cardinality :db.cardinality/one
   }

So I have an entity foo that can contain bar entities (in the foo/barscardinality many ident). Now, I need to lookup the parent foo entity using an attribute from the child bar entity (in this case, bar-description. The way I am trying to achieve this right now is with the following code:

(def foo-id (UUID/randomUUID))
(def bar-id (UUID/randomUUID))
(def foo-data [{:foo/id foo-id :foo/foo-description "foo description 1"}])
(def bar-data [{:bar/id bar-id :bar/bar-description "bar description 1"}])
  (d/transact conn {:tx-data schema})
  (d/transact conn {:tx-data foo-data})

  (d/transact conn {:tx-data [{:foo/id foo-id :foo/bars bar-data}]})

  (d/q '[:find ?foo-desc
         :in $ ?bar-desc
         :where [?bar :bar/bar-description ?bar-desc]
         [?foo :foo/bars ?bar]
         [?foo :foo/foo-description ?foo-desc]]
       db ["bar description 1"])

Given the transacted data, I would have expected the final query to return “foo-description-1", but instead I am getting an empty list. I’m clearly missing something here but I’ve spent the entire day at this point trying to figure it out, so maybe someone here could point out where I’m going wrong. Thanks in advance!

jarrodctaylor15:10:36

In your query I believe you want to pass "bar description 1" as the argument not ["bar description "] For your parent lookup functionality you probably will want to use a https://docs.datomic.com/cloud/query/query-pull.html#reverse-lookup if you haven’t experimented with it already. Something along the lines of:

(d/q '[:find (pull ?e [{:foo/_bars [*]}])
       :in $ ?bar-desc
       :where [?e :bar/bar-description ?bar-desc]]
     (d/db conn) "bar description 1")

Phil15:10:22

remove the square brackets from `["bar description 1"]` in the query (and use (d/db conn) to see the "new" db

favila15:10:51

Your db in the query arg, does it include the results of the transaction? Where was it def-ed? Remember databases are immutable. Consider using the db-after from the d/transact call

DenisMc16:10:36

Thanks for the feedback, that was the problem alright. I had a separate issue with the underlying code from where I derived this simple example which I have also fixed now. Seems to be working well so far.

Phil15:10:41

is there any way to reverse the effect of (datomic.dev-local/divert-system … ?

jaret14:10:33

No, there is no way to un-divert in process.

prnc16:10:28

Hi, I’ve updated to newest version of datomic cloud (ions),

{,,,
"group-cft-version":"936",
"group-cloud-version":"9118",
,,,
"status":"running"}

In release notes: https://docs.datomic.com/cloud/changes.html#936-9118, I’m seeing “Upgraded Clojure to 1.10.3”, yet on ion-dev push, I’m seeing overrides (“The :push operation overrode these dependencies to match versions already running in Datomic Cloud. To test locally, add these explicit deps to your deps.edn.“) to org.clojure/clojure #:mvn{:version "1.10.1"}, I’m not sure how to interpret this? There is this discrepancy on other dependencies as well, it’s quite confusing 😕

prnc18:10:13

Is there a way to check what’s actually on the classpath of an ions system? From the above I gather e.g. that it’s running clojure 1.10.1 and is supposed ot run 1.10.3 according to the changelog, am I misinterpreting?

Daniel Jomphe19:10:52

You probably didn't upgrade ion-dev tool used to :push and :deploy. AFAIR it's that tool that checks the deps to warn about overrides.

Daniel Jomphe19:10:26

In other words, that tool uses a static list of deps and versions, it's not a truly dynamic check.

prnc19:10:34

#Also sent to the channel

hmm, thanks for an idea, but I have I’m on `com.datomic/ion-dev {:mvn/version "1.0.294"}` which is the latest

Daniel Jomphe17:10:09

If you check the first ~50 messages logged in the CloudWatch logstream for your app after a deployment, a few of them contain lots of details and also show the classpath. Those that are about how the system is booted up. (The logstream search field is sometimes useful but can also trip you up.)

prnc17:10:54

Alright! that is a very good tip indeed, will read through that carefully. Thanks Daniel, really appreciate your help!

Daniel Jomphe17:10:32

And I felt sorry to not provide more guidance! Thanks for the appreciation. I'm in a rush... 🙂

prnc18:10:18

This is plenty helpful. Overall datomic is very logical & docs are decent, but sometimes I come across some more opaque corner especially around ops. Community is quite small and it’s not open source so it’s not always easy to find answers, that’s I’m particularly grateful to anyone who gets out of their way to help 🙂 So, Cheers 🍹

🥂 1

prnc19:10:34

replied to a thread:Is there a way to check what’s actually on the classpath of an ions system? From the above I gather e.g. that it’s running clojure 1.10.1 and is supposed ot run 1.10.3 according to the changelog, am I misinterpreting?

hmm, thanks for an idea, but I have I’m on `com.datomic/ion-dev {:mvn/version "1.0.294"}` which is the latest

2021-10-12

Channels