Fork me on GitHub

Hello everyone


Nice to be here


I’m working on a project which uses Datomic Pro


And when I try to run a REPL, I have this error `Could not find artifact com.datomic:datomic-pro:jar:0.9.5561 in central ( Could not find artifact com.datomic:datomic-pro:jar:0.9.5561 in clojars ( Could not transfer artifact com.datomic:datomic-pro:jar:0.9.5561 from/to ( Not authorized , ReasonPhrase:Unauthorized. Could not transfer artifact com.datomic:datomic-pro:pom:0.9.5561 from/to ( Not authorized , ReasonPhrase:Unauthorized. This could be due to a typo in :dependencies, file system permissions, or network issues. If you are behind a proxy, try setting the 'http_proxy' environment variable. Could not resolve dependencies`


any clues? It seems it has to do with the Pro version of Datomic, but I’m not sure, still googling around (never used Datomic before)

Alex Miller (Clojure team)17:01:56

datomic-pro is not available in public repos, you need to use your private my.datomic repo

Alex Miller (Clojure team)17:01:36

or mvn install it locally


I watched this youtube presentation on datomic


in it he mentions that they query runs on the client, with the current value of the database retrieved by the client before the query is executed (if you want, naturally the database as-it-is-now)


What wasn't too clear, I think he said it's held as an optimised tree like structure on the client? If so, I wasn't then too clear what would happen if your database has millions upon millions of entries


Is there a reference to some documentation that explains if your database is huge, how the client handles running queries clientside?


(or indeed, more about how the client runs queries clientside?)


I didn’t watch the video, but “the query runs on the client” is imprecise phrasing. The query runs on peers. There is a separate concept in datomic (a client) which runs queries “over there” on a peer and doesn’t access storage directly--it only asks questions and gets results. (Although in datomic cloud ions the peer may be in-process, so the query doesn’t actually travel on a network.)


The tree structure is blocks of datoms (called segments) in storage; the transactor writes these and the peers read these.


. Peer then deduces which segments it needs to execute the query, and reaches storage for missing segments. Queries can run across datasets that do not fit in memory (by loading and unloading cached segments during DB scans), but the result of query should fit in memory. Query results are not lazy.


thanks for the link! 🙂