Fork me on GitHub
#datomic
<
2016-10-15
>
bhagany02:10:48

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?

arohner20:10:05

@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

arohner20:10:17

though you might be able to do something with transactor functions

bhagany20:10:09

in my head, the spec would realize keys in memory as it checked for them

bhagany20:10:38

just like normal key access for entities

bhagany20:10:47

I think that isn’t too different from what you’d expect from validating other lazily evaluated things

arohner20:10:09

so then you have an implicit pull on every validate?

arohner20:10:19

that will work in some applications, but not all

bhagany22:10:13

More like an implicit touch, but yes, it would potentially be the entire database

bhagany22:10:10

But if you spec the whole db, that's kind of expected