We’ll starting with a crash course on the Datomic data model, and then switch gears to talking about all sorts of data-modeling problems and their solutions.
Digital self-coaching, in the workplace 50,265,275 lovingly crafted, by-a-real-person transactions! Clojure & ClojureScript since April 2012. Datomic since September 2012. In production since Jan 2013!
Before we dive in… some thanks: The Clojure community, for embodying the spirit of sharing and collaboration Rich set out when he started. Ryan and the CR17 team, for the opportunity to speak, and the excellent organisational work. All of you, for your time and attention. Thank you!
And, a very special thank you to the Datomic team: Rich Hickey Stuart Halloway Tim Ewald Chris Redinger David Nolen Marshall Thompson Jaret Binford (and alums Bobby Calderwood and Ben Kamphaus) No doubt many more. These folks have made our lives at Cognician a whole lot better. Thank you!
On questions during this talk: I’m happy to take questions, but I prefer to answer them after my talk.
I’m very happy to do a breakout session where we go Wild West and mess around in a REPL. MC Ryan, please poll our audience to see who’d like to attend a Datomic breakout session?
Database values as global vars. This includes wrapping over a function that automatically calls (d/db (d/connect ...)) for you in a data access layer, so that client functions don’t have to worry about it. Just. Don't. Do it. Treat databases like any other value: pass it around! Keep those functions pure! A tip for web apps: use middleware to inject a db value into your requests, and pass it around from there. This keeps reads for a request on a consistent view of your data.
Source of truth for schema. It’s your database, not your source code. Schema in source code is useful e.g. for creating testing databases, but look to your database for the actual truth. Get comfortable with doing this. You’ll save yourself time! (I have something to share at the end, that’ll help you with this.)
Cardinality-many retractions gotcha. New folks often think that to update a :cardinality/many attribute, they can simply assert the new collection, and magically Datomic will retract all the values not present in the new collection. Some folks get … annoyed, when it doesn’t do this.
Cardinality-many retractions gotcha. I’ve got your back: New folks often think that to update a :cardinality/many attribute, they can simply assert the new collection, and magically Datomic will retract all the values not present in the new collection.
Use Datalog when it’s actually necessary. I particularly encourage you to try to model your queries in terms of d/datoms and normal Clojure functions, even if just to build your understanding of this stuff.
What I hope you got from this. Knowing how the data is modelled by Datomic: Allows you to work with it more like any other in-memory Clojure data-structure, rather than data “over there in the database”. Gives you a major advantage when learning the APIs. Greatly assists you when reasoning about scale. And some practical tips!
One last thing :-) That’s all, folks. Thank you! github.com/cognician/datomic-doc Check out Datomic Doc, a library I released recently, for editing :db/doc strings in a web UI: Twitter: RobStuttaford Github: robert-stuttaford
robertstuttaford
oracle4engineer
skrb
soracom
kohbis
microcms
asei
k1low
chmikata
shohata
tkmnzm
hosimesi11
tacck
colly
eitanlees
holman
bcantrill
marktimemedia
quramy
chrislema
jonyablonski
jponch
danielanewman
jacobian