Fork me on GitHub

So I am just wondering how you all are handling wrapping a Datomic connection inside pedestal/ring and what best practices are? I've seen people store the connection and/or the actual db inside the request map. What is better? or is storing both in the request map the best approach? Seems like storing the db in the request map is overkill to me but I've seen code which does this...


@tmorten: also see the mount framework for minimal configuration management


If I do a pull directly in the query with two dbs, I always get the entity from the first matching database.


That seems like a bug?


Eg :

  '[:find (pull ?e [*])
  :in $1 $2
  [$2 ?e :foo 42]]
  db1 db2)
Now, if both db1 and db2 has an entity with the matching entity id, I apparently get the entity from db1


I would expect the entity from db2


Actually, if the entity isn’t in db1, I just get the db-id. I can then pull specifically from db2, and I then get the entity in full


hi all. i am having a read about datomic and i would like to know whether geolocation/spatial is baked in it. if not, are there recommended ways to do so ? thank you.


Hi @jouerose. It isn’t. But it’s easy to do with an entity consisting of a couple of attributes like the following:

{:db/id #db/id[:db.part/db]
   :db/ident :location/longitude
   :db/valueType :db.type/float
   :db/cardinality :db.cardinality/one
   :db.install/_attribute :db.part/db}

  {:db/id #db/id[:db.part/db]
   :db/ident :location/latitude
   :db/valueType :db.type/float
   :db/cardinality :db.cardinality/one
   :db.install/_attribute :db.part/db}


@luposlip thanks for chipping in. this is new to me. do you think such a solution can go a long way as far efficiency is concerned ?


It depends on what you’re going to use the data for, of course. But in general, yes, due to the architecture of Datomic (most importantly in this case is probably the peer cache)


@luposlip: thanks for your input. it clears it up for me. cheers.


@taylor.sando and @raymcdermott: thank you for the info!


@grav: pull will only pull from first data source in a query (at present) - you should probably just consider behavior for multiple source variables undefined. You’ll note in the grammar: — that a pull expression doesn’t involve a src-var ($).


@jouerose: avet performance from memory is probably ok for some basic point features, if something really needs R-trees to be efficient, nothing in Datomic at present for that.


Is it possible to write a query that will return the keyword name of every attribute in the schema?


here's my first cut:

'[:find [?i ...]
   :where [_ :db/ident ?i]]


Is that everything?



[:find [?i …]
 [_ :db.install/attribute ?a]
 [?a :db/ident ?i]]


Nice! Thank you.


full schema printer invokable with bin/run at (but uses entity touch, not limited to just idents, and also not limited to :


@bkamphaus: I thought all attributes had to be installed in :db.part/db


brain fail from me, yes that’s correct.


I think I mixed that up with how I’ve done it before, which checking now is just relying on implementation detail of where user added attribute entity ids start (at present):

[:find ?i
 [:db.part/db :db.install/attribute ?a]
 [?a :db/ident ?i]
 [(> ?a 62)]]


@bkamphaus: re: pull syntax and multiple dbs. Thanks for the clarification. Currently, we just retrieve entity ids and then pull afterwards. I’m thinking it should be possible to parse the query to automatically figure out which db to pull which entity from. I’m thinking of pursuing that idea. Any comments as to whether it’s possible?


it might be true for your use case but I don’t think it’s true in the general case. I.e. if you’re thinking because ?e was used in a clause with data source var $2, it should pull from there — it’s just a long as far as the query is concerned, even granted specificity of entity id, it’s a really common use case to want to retrieve an entity e.g. from a fn called on the log or an as-of/since database, and then pull things from the most recent database (or vice versa).


I do realize that use case is not a good fit with current lack of ability to specify a src-var in a pull expression, I think that (vs. automatic behavior) is probably the feature request statement of what people want, and the current workaround is to do it outside of query (pull or entity) where behavior is well defined (i.e. you’re passing in the database from which the entity is being projected explicitly.)


@bkamphaus: yeah, too much magic might not be the way to go. Anyway, our current method does work fine, even if it means taking another roundtrip.


@grav: not sure what you mean by another roundtrip in this case simple_smile Remember that composing multiple datomic api calls (datoms, entity, query, pull) hits the memory in your application (when warm), so a roundtrip to database in storage is typically not implied. In your example pull/entity will probably hit same index segment in :eavt as the query, so local memory access only.


You don’t have the same “do everything in one query to avoid roundtrips” motivation that you typically do when building out complex SQL queries. (well, REST API use is an exception here, but pull expressions in query not supported there yet).


@bkamphaus: ah ok. I’m ignorant (eg n00b) as to those kinds of details of datomic simple_smile


No worries, the architecture overview ( ) and memory and caching topics ( ) are good primers on that particular aspect of Datomic.


Cool, thanks!


hi all. any news of an upcoming book on Datomic ?


@jouerose: no news re: upcoming Datomic books.