This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-15
Channels
- # beginners (11)
- # boot (80)
- # carry (1)
- # cider (5)
- # cljs-dev (290)
- # cljsrn (4)
- # clojure (50)
- # clojure-canada (5)
- # clojure-dev (2)
- # clojure-korea (2)
- # clojure-russia (17)
- # clojure-spec (22)
- # clojurescript (41)
- # cursive (12)
- # datomic (10)
- # figwheel (1)
- # hoplon (68)
- # klipse (1)
- # off-topic (1)
- # om (16)
- # onyx (15)
- # parinfer (1)
- # proto-repl (4)
- # proton (2)
- # re-frame (14)
- # reagent (12)
- # ring (5)
- # vim (4)
- # yada (34)
I’ve been putting some hammock time into how one might spec a datomic entity, and right now I’m pondering what spec’s conformance might mean for an entity. My first impulse was that they would conform to maps, which might work. But then, I’m unsure if s/unform
from a map to an entity is a valid concept, because for example, the resulting entity wouldn’t have anything to return from d/entity-db
. I’m also not sure if there’s even a way to create an entity outside of a database context. Anyone have any thoughts on any of this?
@bhagany my bigger issue w/ speccing datomic is that the thing you hold in-memory might not be the whole entity. In spec if you say (s/keys :req [::foo ::bar]), you’re saying in-memory this must have :foo, :bar, which is different from saying the entity must have :foo, :bar. So IMO spec is fine for specific DB queries, but not for general purpose validation