This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-11
Channels
- # adventofcode (129)
- # architecture (10)
- # beginners (163)
- # boot (1)
- # cider (34)
- # cljs-dev (9)
- # clojure (210)
- # clojure-austin (11)
- # clojure-czech (2)
- # clojure-gamedev (1)
- # clojure-greece (67)
- # clojure-italy (2)
- # clojure-russia (8)
- # clojure-spec (36)
- # clojure-uk (54)
- # clojurescript (87)
- # cursive (12)
- # data-science (6)
- # datomic (13)
- # devcards (4)
- # editors (2)
- # emacs (34)
- # figwheel (6)
- # fulcro (147)
- # graphql (17)
- # lumo (54)
- # off-topic (37)
- # om (11)
- # onyx (7)
- # parinfer (10)
- # random (1)
- # re-frame (13)
- # ring (10)
- # ring-swagger (2)
- # sfcljs (1)
- # shadow-cljs (1)
- # spacemacs (32)
- # test-check (4)
- # unrepl (84)
“delete cascade” seems like a good way to think about it too. The same lifetime and ownership considerations exist in sql when deciding to cascade or not
Honestly if you never isComponent nothing will break. You will have to pull those refs explicitly when you want them, and deletion will orphan entities instead of retracting them
Is there any difference under the hood if I use (mapv (partial pull db pattern) eids)
instead of (pull-many db pattern eids)
?
I take it that it is something like: pull-many
only do it once while (mapv pull eids)
does it as many times as how many eids
is there, is this right?
In theory it is possible for pull-many to have much more efficient db access patterns because it knows the full work. In practice I do not know: try it and see if it makes a difference
I’m having issues restoring an older backup to my local dynamodb storage and I’m wondering if anyone can help? the following error is produced by dynamodb in the console: https://pastebin.com/8avZbXD7
I originally backed up my datomic free some time ago, and now I actually need this data again and am trying to get it restored
urgh, looks like ddb-local is completely broken now, will nuke away and restore independent backups and see how it goes
oh snap, ok, so it seems my problem was starting ddb with the -optimizeDbBeforeStartup
flag… it must have corrupted something, somehow
debugging a “not on my box” issue. i’ve packaged an uberjar that runs its own peer, and I’ve included the sql driver in that jar, however when my colleague tries to run it they get java.sql.SQLException: No suitable driver
. jar -tf shows the expected driver names on the classpath. any other obvious things I should check?