This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-24
Channels
- # announcements (13)
- # asami (9)
- # aws (3)
- # babashka (13)
- # babashka-sci-dev (7)
- # beginners (32)
- # calva (59)
- # cider (9)
- # clj-kondo (5)
- # cljsrn (14)
- # clojure (98)
- # clojure-brasil (5)
- # clojure-dev (1)
- # clojure-europe (30)
- # clojure-france (12)
- # clojure-nl (1)
- # clojure-norway (7)
- # clojure-uk (7)
- # clojurescript (20)
- # conjure (2)
- # datahike (7)
- # datalog (38)
- # datomic (29)
- # events (1)
- # fulcro (72)
- # graalvm (1)
- # gratitude (3)
- # helix (7)
- # honeysql (3)
- # improve-getting-started (2)
- # introduce-yourself (1)
- # leiningen (13)
- # lsp (17)
- # malli (11)
- # meander (8)
- # nextjournal (3)
- # off-topic (5)
- # pathom (2)
- # portal (43)
- # rdf (2)
- # re-frame (8)
- # reagent (7)
- # reitit (1)
- # shadow-cljs (27)
- # spacemacs (31)
- # sql (2)
- # tools-deps (3)
- # vim (1)
- # xtdb (12)
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.
Yeah, because it works when I back up my local datomic instance
At least I think I’m sure, based on that.
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.
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?
all atomicity must exist within the boundary of a single transaction
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
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)
to]
:thread/subject subject}
:ent/created_at now
:db/id temp-id))
(transact {:db/id current-user
:user/read true})
You could put two maps {}
in one transact ex. https://github.com/jacekschae/learn-datomic-course-files/blob/f2378c84bade5cb64018f72aa9179a8c8bb25df4/increments/complete/src/main/cheffy/conversation/db.clj#L44
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?@(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))))
@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]]
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.