Business logic with pure data sounds good to me, but I'm no expert. "... Datomic is able to query any data strucutre [sic] that consists of a list of lists." @U0MKRS1FX

;; This is what an actual Datomic DB actually looks like.
(def my-mock-db [
  [123 :name "Test"]
  [123 :email ""]
  [456 :name "Foo"]
  [456 :email "Hello"]])

;; A "normal" query, for good measure.
(d/q '[:find ?person
       :in $ ?name
       :where [?person :name ?name]]
     my-mock-db "Test")
;; HashSet [[123]]

(d/q '[:find ?eid :in $ ?eid :where [?eid]] my-mock-db 123)
;; HashSet [[123]]

(d/q '[:find ?eid :in $ ?eid :where [?eid]] my-mock-db 999)
;; HashSet [[]]

Are you using on-prem? If so I recommend against using d/entity (entity maps) for anything load-bearing. It’s fine and convenient for tests or repl use but elsewhere it is an unpredictable source of io, and it’s very easy to lose track of what the data dependencies are over time (that’s it’s power and it’s liability). Also people seem continually surprised by its equality semantics

Use pull expressions and project your data into maps that are the same shape as your data (or as near as you can manage)

Keep keyworded attributes the same “type” in your app and your database, so they obey the same attr predicate. (Doubly so if you use spec)

For extra expressive power, you can have functions declare the pull expression shape of the data they expect (transitively) and use this info to compose them into larger expressions

Also remember that entities are not maps. Expect and embrace the asymmetry between reads and writes. Try to frame writes as datafied commands in their own right that produce (or are) tx data with db/ensure, tx fns, etc to provide integrity

For querying, try encapsulating “business logic” query concepts as named rules so they can be recomposed into larger queries (rules can be polymorphic! Just define the same rule name multiple times)

Do be aware of performance though. Datomic doesn’t do clause reordering, which is really unfortunate and dangerous for rules

Also keep query concerns to “find the matching entities” and pass in pull expressions for “what I want from those entities” as a parameter (or just use pull-many)

(By analogy, in sql terms you want to separate the “select” from the rest of the query)

Thanks, great ideas 👍

I'm a bit torn here. Since the whole db is represented as an immutable value, I kind of also like the idea of just passing the db around and have various functions extract what they need directly from the db. This avoids having to create a separate mapping view of what's in the db, as well as having to know "outside" what needs to be pre-fetched from the db into maps, etc. And for tests, it's trivial to set up a db that contains what you need using with

I'm not convinced that "hiding" the db adds all that much value, really

what about leveraging spec/schema to generatively test functions? I would imagine that it's not trivial to generate data for functions which expect entities?

that's a good point! I've only used generative tests for parts of my code that doesn't know about datomic dbs, and I've also not really used spec/schema either

(also, one argument (in favor of entities) I've heard is that it's a lot easier to accidentally write a really slow query that makes your prod environment slow to a crawl as opposed to pay a smaller performance penalty all the time when traversing between entities)

I suppose that the code I'm talking about that reads in a datomic db, is the part of my code that returns a plain map that I use for rendering GUIs etc 🙂

I tend to allow all that code that sits "between" the db and the rendering to access the full db, and that creating plain maps first and then processing plain maps to generate the GUI data is not something I tend to do a lot

should be noted, my context is datascript + frontend, not actually datomic per se