This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-14
Channels
- # beginners (33)
- # boot (38)
- # clara (21)
- # cljs-dev (1)
- # cljsjs (2)
- # cljsrn (12)
- # clojure (230)
- # clojure-argentina (1)
- # clojure-brasil (3)
- # clojure-dusseldorf (4)
- # clojure-france (9)
- # clojure-italy (1)
- # clojure-russia (123)
- # clojure-spec (46)
- # clojure-turkiye (1)
- # clojure-uk (60)
- # clojurescript (83)
- # core-async (6)
- # cursive (10)
- # datascript (19)
- # datomic (28)
- # defnpodcast (1)
- # emacs (7)
- # figwheel (7)
- # fulcro (29)
- # leiningen (29)
- # lumo (9)
- # off-topic (14)
- # om (1)
- # onyx (25)
- # pedestal (1)
- # protorepl (3)
- # re-frame (10)
- # reagent (41)
- # ring-swagger (11)
- # shadow-cljs (10)
- # testing (5)
- # unrepl (3)
- # vim (3)
I was wondering if somebody has already experimented with persisting datascript DBs on the file system or on something like sqllite.
@U0FR867U1 i just send datoms to my db, indexed on t, grouped by e+a
i pull out the "latest" v's for each e+a and send them all back to datascript when needed
Hey man thanks for the reply. I am sure there are more subtleties to your method though. I’ll keep it in mind.
not really tbh
it gets trickier if you want to share your datoms across different users/devices
but if it's 1:1 there's not much to it
@U0FR867U1 I have a very "dumb" version as well by just shoving a datascript db in a duratom from here https://github.com/jimpil/duratom
(ns durascript
(:require [datascript.core :as d]
[datascript.db :as ddb]
[duratom.core :as duratom]
[taoensso.nippy :as nippy]
[ :as io]
[clojure.edn :as edn]
[duratom.utils :as duratom-utils])
(:import ( PushbackReader)))
(nippy/extend-freeze clojure.lang.Atom
::atom ; A unique (namespaced) type identifier
[x data-output]
(.writeUTF data-output (pr-str @x)))
(nippy/extend-thaw ::atom ; Same type id
[data-input]
(atom (edn/read-string (.readUTF data-input))))
(nippy/extend-freeze datascript.db.DB
::DB ; A unique (namespaced) type identifier
[x data-output]
;;(println "type:" (type data-output))
;;(.writeUTF data-output (pr-str x))
(#'nippy/write-utf8-lg data-output (pr-str x))
)
(nippy/extend-thaw
::DB ; Same type id
[data-input]
(edn/read-string {:readers d/data-readers}
(#'nippy/read-utf8-lg data-input)))
(defn read-db-edn-from-file!
"Efficiently read large data structures from a stream."
[source]
(with-open [r (PushbackReader. (io/reader source))]
(edn/read {:readers d/data-readers} r)))
(defn edn-db [file-path]
(with-meta (duratom/duratom :local-file
:file-path file-path
:init (ddb/empty-db)
:rw {:read read-db-edn-from-file!
:write duratom-utils/write-edn-to-file!} )
{:listeners (atom {})}))
(defn nippy-db [file-path & [schema]]
(with-meta (duratom/duratom :local-file
:file-path file-path
:rw {:read nippy/thaw-from-file
:write nippy/freeze-to-file}
:init (if schema
(ddb/empty-db schema)
(ddb/empty-db)))
{:listeners (atom {})}))
@U0D4G0Q4U I am starting to see how you do it now that my brain had time to process the info... @U064UGEUQ Thx, th aproach is an interesting one also I will think about it too.
yeah, there's always pr-str
, lol
depends if you want to somehow preserve historical info or not
True and pr-str
isn’t far from the transit solution... The thing is, it would be nice to be able to embed datomic in an app without having to start a transactor in another process and having it running in JS instead of Java for electron apps... Short of that I am seeing what can be done with datascript.
@U0FR867U1 you can run datascript in clj and cljs, so you have a lot of freedom there
as long as you don't want to try to do distributed state, or historical queries
then persistence is very simple with datascript and you should keep it that way 🙂