@rustam.gilaztdinov in my experience, maybe you need to add an extra parameter useSSL=false in the url, and have you installet postsql library in the project.clj and in the transactor's lib folder?

@joseph I just try to up docker-compose, not using in clojure project. > in the transactor’s lib folder? Can you clarify what is that mean?

I mean when you use some specific database like postsql behind datomic, you also need to give it library to both transactor and the project.clj

for example, I use mysql, so I need to download mysql-java connector and move it to the datomic's lib folder

this is the part of my Dockerfile:

ENV DATOMIC_VERSION 0.9.5561

ENV DATOMIC_HOME /opt/datomic-pro-$DATOMIC_VERSION

ENV DATOMIC_DATA $DATOMIC_HOME/data

ENV MYSQL_CONNECT_VERSION 5.1.41

RUN apk add --no-cache unzip curl wget

RUN mkdir -p $DATOMIC_HOME/lib

RUN mkdir -p /usr/datomic/config

RUN wget  -O /tmp/mysql-connector-java.zip \
    && unzip /tmp/mysql-connector-java.zip -d /tmp \
    && cp /tmp/mysql-connector-java-$MYSQL_CONNECT_VERSION/mysql-connector-java-$MYSQL_CONNECT_VERSION-bin.jar $DATOMIC_HOME/lib \
    && rm -fr /tmp/mysql-connector-java.zip /tmp/mysql-connector-java*

and to connect to the postsql from client, you also need to add its library in the project.clj, for example, i am using mysql, so I need to add this [mysql/mysql-connector-java "5.1.41"] in the dependencies in the project.clj

About connector in Dockerfile — that’s interesting In doc about setting up storage — http://docs.datomic.com/storage.html — nobody mention that

@rustam.gilaztdinov hmm... it seems datomic has already contained the postsql library in the lib folder

@rustam.gilaztdinov it's mentioned here: http://docs.datomic.com/storage.html#sec-5-1

Yes, I see But when I want just build storage with peer and transactor — no need for this, right?

build storage with peer and transactor? I think it's for it or maybe I misunderstand you...

when transactor connects to the postsql, it needs the postsql connector in its lib folder

Is it possible to do negation over a collection binding

(d/q '[:find [?e ...]
       :in $ [?ages ...]
       :where
       [?e :ages _]
       (not-join
         [?e ?ages]
         [?e :age ?ages])] db [1 2 3 4])

(d/q '[:find [?e ...]
       :in $ [?ages ...]
       :where
       [?e :age ?ages]] db [1 2 3 4])

@mbutler will this work for you?

(d/q '[:find [?e ...]
         :in $ ?excluded-ages
         :where
         [?e :age ?age]
         (not [(contains? ?excluded-ages ?age)])]
       db #{1 2 3 4})

@uwo had considered that, only hesitant that the inverse query would be so vastly different, dont know the perf implications of datomics set comparison vs contains? maybe there is a lesson in there about using clojure in datalog.

Something in me wants it to work with the collection binding.

Where would I report a typo in a Datomic doc page? Specifically the description of parameters to tx-data http://docs.datomic.com/query.html seems to be garbled: "Given a log and a database, tx-data returns a collection of the datoms added by a transaction." In fact (and according to the example on that page) tx-data is given a database log and a transaction.

@jaret @marshall ^ 🙂

When handling references on the front end, do most of you work with the :db/id from datomic? I have a colleague that thinks datomic ids shouldn’t leave the server, and if you need to refer to a ref within datomic you should use a uuid. I don’t personally see a need to use uuids until I’m communicating with a separate system. (of course, there is the question of where that line begins)

@uwo have done it both ways, creating uuid with squids and using them externally and just using the :db/id everywhere. Your IDs and by extension potentially your urls (in the case of a rest api) become very predictable. Don't know if you would consider that a concern?

@mbutler definitely something to weigh. good point

I guess I would put that in the category of authorization

@uwo I never expose db/id to users or other systems, but will use them internally for short-lived uses

not so extreme as never transact anything by id

(which is in fact impossible in many cases, e.g. updating a component id)

:db/id will not survive across migrations too, that's why datomic supports :db/unique and lookup refs