Fork me on GitHub

datomic allows different db's, any rule of thumbs of how data should be partitioned into different dbs ? My assumption is that the peers will have the indexes / cache of only the dbs to which it is connected, so that could be a determining factor.


I guess I'd start with a baseline rule of: don't partition your data into multiple dbs unless it's absolutely necessary. If it is necessary, your problem domain should make it clear what you need to do, e.g. regulatory restrictions on how/where you are allowed to store data. If the need doesn't arise from the domain, I'd venture that you are working around a deeper problem and you should attack that first.


is there a way to d/pull many ? in the cloud datomic api? I have list of db/id's and want to pull all entities.


I can't do this kind of thing

(d/q '[:find (pull ?e pattern)
             :in $ pattern [?product-ids ...]
             [?e :db/id ?product-ids]]
        (d/db conn) '[*] db-ids)


What is ?product-ids ? Are these the natural entity ids of datomic itself? Either way, you can do exactly what you want, no need to match on :db/id.

(d/q `[:find (pull ?product-ids [*])
       :in $ [?product-ids ...]]
        (d/db conn) db-ids) 
More commonly, you might have some actual product ids that you use:
(d/q `[:find (pull ?product [*])
       :in $ [?product-id ...]
       :where [?product :product/id ?product-id]]
         (d/db conn) product-ids)
Assuming :product/id is your attribute for product id


@UEC6M0NNB Key to remember is that you're not forced to use :where, if you have the db/ids already just literally match on them. You can pull many this way.


holy crapoley @UNRDXKBNY => now that is some good teaching. Works perfectly. Never knew that I could drop the where. So simple. Thanks for taking the moments to explain this

đź‘Ś 4

since this throws error

Unable to resolve entity: :db/id


what about using pull-many without query? If you have only db/id matching condition, query is not not the right way, but pull is


pull-many is not available in cloud api ( unfortuneately .. good question


Pull-many can be implemented in cloud via a simple wrapper around a query


i think i know what you mean .. very good point actually.


why not (map #(pull ...)) btw?


Speed. On client each pull is an http request round-trip. On peer work can be shared between calls or could be done in parallel


Datomic provides attribute preds and entity preds, usually such validation will happen in the application layer. From a design perspective in what scenarios should the above be used to validate data in the DB layer too ?


Attr preds are mostly for safety. Entity preds are protection from data races


Ie there may be an invariant you can’t guarantee without reading the state of the db right before committing the tx. Entity preds are the only thing that can do this

Jacob O'Bryant02:04:53

and transaction functions


Transaction functions can only read the “before transaction” value of the db, so its possible to run two tx fns In the same tx which violate an invariant when run together (eg two counter incrementers). entity preds read the “after transaction” value but can abort the transaction if a constraint is violated

Joe Lane15:04:44

@U09R86PA4 Now THAT is interesting. I had never considered that, thanks!


aka implement your own system for managing consistency


Hey! I’ve hit something unexpected in Datomic. After storing vector in database it’s being pulled out with elements ordered differently.


Should I look for some weird bug in my code? Or it’s desired behavior? (That would be terrible!)

Jacob O'Bryant02:04:09

That's expected behavior. Multi-cardinality values in Datomic are unordered. To preserve ordering you'll have to model it explicitly.


Datomic and datalog operate on sets not lists


That's just a notational convenience that you can specify multiple values for an attribute as a vector. You can also use a set literal (`#{val1 val2}`); that conveys the intent more precisely, but not every language has native support for representing sets concisely.