Fork me on GitHub
#datomic
<
2022-03-24
>
manutter5112:03:19

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.

favila12:03:29

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

manutter5112:03:14

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

manutter5112:03:43

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

favila12:03:16

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

favila12:03:45

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

manutter5112:03:54

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.

manutter5112:03:22

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

favila12:03:22

the datomic distro does not include mssql out of the box

👍 1
favila12:03:07

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

favila12:03:44

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

manutter5112:03:47

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

manutter5113:03:51

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.

manutter5113:03:01

Thanks for setting me straight.

zendevil.eth16:03:11

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

zendevil.eth16:03:32

Basically I want to make these two atomic:

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

zendevil.eth19:03:51

I have the following:

@(d/transact-async
             @conn
             [(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?

kenny19:03:56

@(d/transact-async
   @conn
   (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]]

kenny22:03:59

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.

ghadi19:03:19

@ps first step of debugging is to take things apart

ghadi19:03:35

pull out the tx-data expression out of the call

ghadi19:03:37

and look at it

ghadi19:03:47

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

😆 1