Fork me on GitHub

I’m trying to take a backup of a remote (QA) datomic on-prem instance, which I’ve done many times before, but now I’m getting a stack dump headed by java.sql.SQLException: No suitable driver. I’m using the same database URI as the QA web server, and I do not get this error when backing up a local datomic instance. The QA web server is on a different host from the QA datomic instance. It seems like I can verify that each of the individual pieces are correct: my local datomic install works, the URI works, the connection works over the network, etc. Any idea where I can start looking to debug this? I’ve done some googling, but nothing helpful has turned up so far.


You’re sure that the jdbc driver you need is on the classpath of the backup process?


Yeah, because it works when I back up my local datomic instance


At least I think I’m sure, based on that.


what is “local datomic” here, a sql database of the same kind as the remote one?


e.g. both are postgres, or both are mysql, etc


Hmmm, ok, that’s a good point. Now that I think about it, I believe my local dev box is just using h2 instead of MSSQL. So now I’m no longer sure I do have the right driver on the path. It always used to work correctly though, and I certainly haven’t deleted any drivers from the path.


Let me dig into this some more, thanks for poking at my assumptions.


the datomic distro does not include mssql out of the box

👍 1

maybe you previously used a patched distro (copied the driver jar into libs or something), but upgraded versions and forgot this step?


whatever was done to the datomic distro that is running the transactor was probably not done to the directory running the backup


Yeah, or some recent update messed with my predefined paths or something. Time for the sleuthing hat.


Ok, that was it. Copied my SQLServerDriver-6.0.jar from the .m2 directory into datomic/lib, and it’s working now. I was getting stuck because I forgot my local backing store was H2 instead of MSSQL, so I was assuming all my drivers were in place.


Thanks for setting me straight.


Is it possible to make two (transact …) atomic, i.e., either both transact or both fail if one fails?

Adam Lewis16:03:16

all atomicity must exist within the boundary of a single transaction

Adam Lewis16:03:02

but if you serialize two transactions, you can make the second depend on the first. but no way to, e.g. roll-back the first if the second fails

Adam Lewis16:03:58

there are some techniques you can use to manage this, however...trying to find some references


Basically I want to make these two atomic:

(transact  (assoc  {:thread/users
                [(:db/id current-user)
                :thread/subject subject}
                              :ent/created_at now
                              :db/id temp-id))
(transact {:db/id current-user
           :user/read true})


I have the following:

             [(assoc  params
                      :ent/created_at now
                      :db/id temp-id)
              (map (fn [to]
                     [:db/retract to :user/read (:message/thread params)])
                   (:message/to params))])
but I’m getting:
{:error "java.lang.IllegalArgumentException: :db.error/invalid-lookup-ref Invalid list form: [:db/retract 17592186045444 :user/read 17592186045450]"}
Why is that the case?


   (into [(assoc params
            :ent/created_at now
            :db/id temp-id)]
     (map (fn [to]
            [:db/retract to :user/read (:message/thread params)])
       (:message/to params))))

Björn Ebbinghaus22:03:45

@ps Did you know that you probably don't need the :ent/created_at attribute? Datomic already stores the time for each transaction, and you can query for the transaction where a fact was added. The following query finds the last time the :message/id was changed for a given message.

[:find ?message ?created-at
 :in $ ?message
 [?message :message/id _ ?tx]
 [?tx :db/txInstant ?created-at]]


Generally, I would not recommend using transaction time to model domain information.

Björn Ebbinghaus23:03:16

You are absolutely right. 🙂 Honestly, I am a bit confused why I wrote that message. I don't even do it myself... Time to go to bed, I guess.


@ps first step of debugging is to take things apart


pull out the tx-data expression out of the call


and look at it


kenny is distributing fish, but better to teach a person to fish

😆 1