Fork me on GitHub

for aws, the atomic solo 1 monthly estimate is $118 whereas the production 1 is $21, is this correct? I thought solo was more affordable/suitable for getting started - did this change?


This is an error in marketplace


The estimates should be reversed


We are working with aws to correct

Jon Walch22:11:14

Would you mind letting me know when this is corrected? I'd like to stand up a Solo 1 ASAP


You can use solo as it is


The price you are charged is correct


Its just the display on the marketplace site that is wrong

Jon Walch23:11:30

The CloudFormation template for Solo is also making reference to the instance sizing in production 1

Jon Walch02:11:37

I just went through the process for setting up a Solo 1. If I look at my EC2 instances, my bastion is a t3.nano and then I have two i3.large instances? Is this correct?


That is not correct


that is a production topology


What version did you launch from Marketplace?


@UNVU1Q6G1 Can you follow the directions here and launch a stack from our Releases page instead of from Marketplace I will contact AWS today and look into getting the listing corrected


@UNVU1Q6G1 I believe this may be an issue with the “535-8812.1” release. Can you try the one without the .1 (just 535-8812) ?


so does that mean i should solo 1 despite the large estimate, since the actual amount will be reversed?


ok, thanks for clarifying !


i'm curious -- what makes the following two queries different enough to return empty vs. non-empty results?

; find entities whose :user/name attribute has a value of "user123"
(d/q '{:find  [?e]
       :in    [$ ?v]
       :where [[?e :user/name ?v]]}
     db "user123")
=> [[12345678912345]]

; find entities with any attribute (unbound) that has a value of "user123"
(d/q '{:find  [?e]
       :in    [$ ?v]
       :where [[?e _ ?v]]}
     db "user123")
=> []


That is pretty alarming


Maybe :user/name is not indexed?


Nonetheless, my expectation is the second query would not be empty; it might be so slow it never terminates, but not empty


is there a way to find out? perhaps it's just me? i can definitely reproduce it.


To me this looks like a bug


it’s a pathological case, you’d never want a query like [?e _ ?v] as the first clause with ?v bound, but it should still work


experiment with binding ?a in various ways, see if it gives results


> Nonetheless, my expectation is the second query would not be empty; it might be so slow it never terminates, but not empty i did wonder if this would trigger a full-db scan alert, however an empty set (returned instantly) made me scratch my head.


[0 :db.install/attribute ?a] [?e ?a ?v] or filter down further


i did try binding ?a with the same result


[?a :db/ident :user/name] [?e ?a ?v]?


same result meaning empty set?


[?a :db/ident :user/name] [?e ?a ?v] works as expected


simply binding ?a (and not using it) returns an empty set


I meant forcing ?a to be bound to every attribute explicitly


It could be the query planner refuses to even try to match by ?v if it doesn’t know ?a


there’s no index it can use effectively after all


I would still want an error not a silent empty set


interesting, this works!

(d/q '{:find  [?e ?b]
       :in    [$ ?v]
       :where [
               [?a :db/ident ?b]
               [?e ?a ?v]]}
     (client/db) "user123")
=> [[12345678912345]]


(by the way, i would never use queries like these in production. this only stemmed from some hacky experimentations.)


however, my concern is that an empty set can be dangerously misleading


FYI, I reproduced this with the same results and it’s not what I expected. Adding the [_ :db/ident ?a] or [?a :db/ident] clause works (and is considerably slower).

👍 4

Adding a predicate clause [(= ?v ?name)] [?e _ ?name] will warn you of a full db scan


also curious -- is it normal to see what look like duplicate references in :db.alter/attribute?

{:db/id              0
 :db.alter/attribute [#:db{:id 99, :ident :user/name}
                      #:db{:id 99, :ident :user/name}]}


That is an issue that was resolved in the most recent release


hello i'm requesting datomic in a new boot app, and receiving a Could not locate datomic/client/impl/pro__init.class error. is there a way I can go about in resolving this? here's my require code: (:require [datomic.client.api :as d]) here's my dependency: :dependencies '[[org.clojure/clojure "1.10.0"] [com.datomic/client-cloud "0.8.78"]]

Jon Walch21:11:27

your require and deps look fine to me


figured out it's not a dependency error it's a connection error

Jon Walch21:11:37

I'm trying to read an edn file from my code base and then transact it, If I copy it verbatim and paste it in as the tx-data it works fine, however if I try to read it as a resource, slurp, and edn/read-string it, I get the following when I try to transact it

   :message :db.error/not-a-data-function Unable to resolve data function: #:db{:doc "User first name", :ident :user/first-name, :valueType :db.type/string, :cardinality :db.cardinality/one}
   :data #:db{:error :db.error/not-a-data-function}
   :at [datomic.error$arg invokeStatic error.clj 57]}]
I think its because edn/read-str is using the Map namespace syntax (, is there a way to force it not to?

Jon Walch22:11:55

I'm just going to declare my txs in code instead of in edn

Alex Miller (Clojure team)22:11:08

whether you use that syntax, or not, the map in memory is identical

Alex Miller (Clojure team)23:11:26

the error makes it sound like you've got an attribute definition where datomic expects a function, which seems like something else


if we're using datomic cloud, what setup is recommended for dev and staging? i'd rather not create two more cloud instances, so it OK to use datomic free for these scenarios?

Jon Walch02:11:13

You can but the API is different

Jon Walch02:11:48

I tried fiddling with but it didn't work quite right for me


so is the expected solution to create/pay for separate cloud instances?


or I guess wrap both cloud/on-premise APIs to make them the same


datomic cloud does not have a local-dev story


you are expected to have something running in the cloud, even for test runners


@UNVU1Q6G1 What did work? @UPH6EL9DH We use datomic-client-memdb for running unit tests & gen tests on CI. We also have a dev system always running which lets you connect locally to run integration tests. The Datomic client for this dev system is created by specifying a "prefix" which will get added to all DBs created. We just implemented a simple wrapper around datomic.client.api.protocols/Client.

Jon Walch18:11:05

@U083D6HK9 It was working perfectly for transacting. When I was trying to do (d/db conn) where conn is a datomic-client-memdb LocalConnection, it was telling me that the type couldn't be cast. Let me see if I can repro

Jon Walch18:11:14

java.lang.ClassCastException: class compute.datomic_client_memdb.core.LocalConnection cannot be cast to class datomic.Connection (compute.datomic_client_memdb.core.LocalConnection is in unnamed module of loader clojure.lang.DynamicClassLoader @1e420b95; datomic.Connection is in unnamed module of loader 'app'


Can you send the full code you’re using to do that @UNVU1Q6G1 ?

Jon Walch19:11:02

Spoke with @U083D6HK9 in a DM, it was user error on my part 😄


@U083D6HK9 so to be clear you're not running two cloud instances, just one instance but for dev you prefix all databases created?


@UPH6EL9DH yes — one instance with multiple devs using the same instance. Each dev makes their own prefix.


@U083D6HK9 would you be able to share some of the wrapper code? 🙂 also, even with a prefix, are you not concerned at all about mixing production and dev database?


I can see how coupled to other code our wrapper is when I get back in front of a computer. Might be able to paste some code here. Oh, I guess we run two systems then. One for production. Dev and QA environments both use the single Datomic dev system.


@U083D6HK9 that'd be great thanks; and yea, that seems like best solution, but for a side project jumps cost for 30$ monthly to 60$ which can get pretty steep


I think you’d honestly be fine running prod and dev on the same system. Make it so prod uses no prefix.


We run separate topologies so we get high availability. Dev is just running solo.


@UPH6EL9DH It's essentially this:

(defrecord DatomicClient [client db-prefix return-anomalies?]
  (list-databases [_ arg-map]
    (let [dbs (d/list-databases client arg-map)]
      (into (list)
              (filter (fn [db-name]
                        (if db-prefix
                          (str/starts-with? db-name (db-prefix-str db-prefix))
                          (not (str/starts-with? db-name "__")))))
              (map (fn [db-name]
                     (str/replace-first db-name (db-prefix-str db-prefix) ""))))
  (connect [_ arg-map]
    (d/connect client {:db-name (prefix-db-name db-prefix (:db-name arg-map))}))
  (create-database [_ arg-map]
    (d/create-database client {:db-name (prefix-db-name db-prefix (:db-name arg-map))}))
  (delete-database [_ arg-map]
    (d/delete-database client {:db-name (prefix-db-name db-prefix (:db-name arg-map))})))


@U083D6HK9 great, thanks for sharing 👍


I’ve some issue installing Datomic Pro Starter Edition I created a file ~/.lein/credentials.clj

{#"my\.datomic\.com" {:username "…."
                      :password "…."}}
then generated ~/.lein/credentials.clj.gpg gpg --default-recipient-self -e ~/.lein/credentials.clj > ~/.lein/credentials.clj.gpg added to my project.clj
:repositories {"" {:url ""
                                 :creds :gpg}}
:dependencies [[com.datomic/client-pro "0.9.5927"]]
but when i run lein deps I get
Could not find artifact com.datomic:client-pro:jar:0.9.5927 in central ()
Could not find artifact com.datomic:client-pro:jar:0.9.5927 in clojars ()
Could not find artifact com.datomic:client-pro:jar:0.9.5927 in  ()
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.


the client-pro version is not the same as the datomic version

👍 4

client library is in Maven: latest version is 0.9.37