This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-07
Channels
- # beginners (41)
- # boot (38)
- # cider (17)
- # cljs-dev (52)
- # cljsjs (3)
- # clojure (200)
- # clojure-italy (8)
- # clojure-russia (50)
- # clojure-spec (28)
- # clojure-uk (45)
- # clojurescript (28)
- # core-async (9)
- # core-matrix (2)
- # cursive (16)
- # datascript (15)
- # datomic (50)
- # dirac (5)
- # emacs (20)
- # figwheel (8)
- # flambo (2)
- # hoplon (10)
- # incanter (1)
- # jobs (1)
- # leiningen (2)
- # lumo (26)
- # mount (171)
- # off-topic (22)
- # om (54)
- # onyx (2)
- # pedestal (27)
- # re-frame (10)
- # reagent (12)
- # ring (27)
- # ring-swagger (3)
- # rum (2)
- # slack-help (1)
- # spacemacs (134)
- # specter (6)
- # sql (15)
- # testing (20)
- # uncomplicate (5)
- # unrepl (49)
- # untangled (9)
- # yada (29)
so when i try to connect using a sql connection string, the peer: - hits storage - determines the configured host and alt-host - peer tries to hit host or alt-host to talk to the transactor is that right? wondering how i'm going to connect to my in-cluster datomic from my dev machine when its dns isn't accessible from outside.
Is there a way to extract all current (non-retracted) datoms without getting all of them, comparing timestamps and added?
flags, and building a model of the database?
ref "building a model for the database" - not sure what you're planning there, but I would just dump plain facts, no structured entities etc
It looks like the first few are system facts that I don’t need to copy out. Is there an easy way to detect that?
User attributes are added to the db partition, too, right? So that doesn’t really tell me.
I could create an empty database and remove common facts. Assuming eids of the system things never change, I should the be able to transact that to a different database (in a test environment).
you could look up the transaction that wrote those entities and see if it has something interesting on it
perhaps they're all from the same transaction, and that transaction has something you can use to identify that it is the "boostrap" tx
This is a bit old now, but some of the gotchas about the "dump a restorable db to edn" are still there
e.g. the one you mentioned, that there are bootstrap datoms you should not keep/restore
also this is tuned for memory dbs back when they did not have logs. Nowdays if you want to keep full history it's better to use the tx log directly
I mean, its not true for me:
(first (d/datoms (db) :eavt))
#datom[0 10 :db.part/db 13194139533312 true]