This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-09
Channels
- # announcements (1)
- # architecture (20)
- # aws (22)
- # babashka (41)
- # beginners (191)
- # chlorine-clover (66)
- # cider (19)
- # clj-kondo (54)
- # cljs-dev (15)
- # cljsrn (78)
- # clojars (1)
- # clojure (148)
- # clojure-android (4)
- # clojure-europe (7)
- # clojure-gamedev (15)
- # clojure-germany (6)
- # clojure-losangeles (46)
- # clojure-nl (23)
- # clojure-survey (3)
- # clojure-uk (46)
- # clojurescript (24)
- # conjure (21)
- # cursive (21)
- # data-science (11)
- # datomic (5)
- # events (2)
- # fulcro (28)
- # garden (32)
- # joker (2)
- # kaocha (6)
- # lambdaisland (4)
- # mount (2)
- # off-topic (11)
- # pathom (10)
- # pedestal (13)
- # re-frame (7)
- # shadow-cljs (15)
- # spacemacs (21)
- # specmonstah (1)
- # wasm (1)
- # windows (1)
- # xtdb (37)
What is the recommended database to use with fulcro? It doesn't look like EQL provides any mechanism to actually store data. Also is there a section in the book which talks about this because I can't find anything.
Thanks!
If you're using pathom in the backend, as is recommended, you can use whichever data store you like. I tend to use postgres, myself.
i used to recommend datomic (we built our product with datomic), but with pathom and RAD i’d strongly consider postgres
datomic is still really nice, but postgres is just so battle hardened, extensible, and has so many features
in datomic you still can’t store local-dates, you have store strings, just one example
that said it definitely depends on what your are building, in general can’t go wrong with either IMO
@U09FEH8GN about dates, you can store #inst
on datomic, right?
right only insts
none of the other java time types
Evaluating RAD for a project, and wanted to check if anyone had written a database adapter for Datomic client/cloud yet? I’m about to do just that, but wanted to check if someone had already done it, would save me a couple of hours.
not that I know of @mdhaney. If you can adapt the one that is already there, I’d appreciate it…it seems like one adapter should be able to support both?
I think it is just a matter of getting rid of the small number of uses of the entity API (one I can think of) and checking to make sure pull-many is covered
Yeah, getting rid of entity api is pretty easy, and I wrote a replacement for pull-many for a previous project, so should be covered there.
I’m going to try to do it in the same adapter. Might be tricky with the different dependencies, but should be possible using different deps aliases. I’m thinking a datomic-client alias alongside the existing datomic alias should do the trick.
The plugin does not have a Datomic dependency. You are required to pull one in to use it…so that should be ok