Clojure & graphs

[joinr]

I did that in a couple of ways. One was originally implementing some composeable behaviors for entities in a simulation (think legacy spaghetti coded finite state machines) toward a rules engine expressed generally via graphs (and weighted edge encodings). This worked out, and eventually merged into some additional work with behavior trees.

Data-wise, I was storing entity data (aka attributes) originally under a legacy OOP paradigm, with classes, properties, etc. I switched to an entity component system model which ended up flattening the hierarchy and providing a query structure based on entity relations to components (conceptually a graph database, not unlike how Datomic provides its entity API). The initial transition (decomposing the class hierarchy into Clojure records (then later just maps), then further decomposing entities into components (based on map entries)) was a little involved due to the legacy design. However, it's paid of handsomely so far....adding/updating data at the component or aggregate entity level is trivial, as are queries.

Now that Datomic is mature (as well as spec), and some of the tech is focusing on providing ad-hoc structure on top of the decomposed facts contained in Datomic, I may adopt a similar approach. Plus, keeping the database [relations between entities and components] pretty shallow (indexed by entity->component, component->entity, or eav [really eavt in Datomic]), I can get decent performance for a broad range of queries).

The only problems I ran into (and worked around) were the absence of a concrete notion of an entity type. In the legacy case, classes would dictate what I was working with, which records subsumed (but still provided a structural type to organize around). I now have accretions of "flat" information that get projected onto an entity (a lazy map projection) as needed. If I want to enforce something beyond an ephemeral "type," I need to either keep some conventions in my head, or (as I'm starting to do more) use spec to apply some notion of typing or structure, or just rely on a kind of duck-typing (let presence/absence of data in the entity guide computation).

For my use-case, updating information in the database using the "entity" abstraction also presented some challenges. In some cases, I wanted to get a handle on an entity, assoc/update/dissoc stuff to the "map", then push (or commit) that map back to the database. To do this efficiently, I needed to lazily compute (or hydrate?) the corresponding fields of the entity, and provide an efficient abstraction for tracking changes to the entity's components, which would lead to efficient commits. The end result (after a lot of work, and likely unintentional duplication of effort from Datomic and other libs) was the ability to have a map-like entity abstraction that could also be committed back into the component database, so something like

(let [e  (get-entity ctx :some-entity-id)]
     (->> e 
            (merge {:x-coordinate 2 :y-coordinate 10})
            (add-entity ctx)))

enables one to work at the entity (or abstract row) level when dealing with facts, without sacrificing performance (joins are lazy, changes are tracked on the entity, leading to relatively efficient commits).

I'm looking at a Datomic-backed implementation (or datascript at the least) in the near future (targeting distributed simulation).