hi. Our application uses a sql db (postgress/oracle) and mongo. One of the concerns we hear from customers is, they dont want to deal with multiple databases (different database admins).. we store json documents into Mongo. We are thinking of datomic for other considerations. But, question remains whether we can remove Mongo from the application and use datomic for that purpose too. Any suggestions ?

> and use datomic for that purpose too @wistb I don't understand, what purpose is this?

@wistb it depends. Datomic isn't a document store where you can invent new keys on the fly. Datomic is a graph database where any entity can have any attribute that's already defined up front in the schema. The other drawback for your scenario is that you're turning a setup that looks like: http://www.plantuml.com/plantuml/png/IqaiIKnAB4vLyCtFIy_dIe5n0_ABIzABKekvkA8T2mfoCfCJIpBpys8LT5Foo_DqxQ3AiSl1z080 and turning it into: http://www.plantuml.com/plantuml/png/IqaiIKnAB4vLS4aioS_DJEPAWGa4v1UNf1Ub5dDnHJiM5EHa9YUMPERdnIhefkINv-dQmJL0QRWuJ1y0 which is still the same number of nodes, even if a different hierarchy. So it may not solve your customers problems.

@dominicm You are right about "the number of database boxes is still 2 ", but, is it true that there is a 'datomic admin' role (in the same meaning of 'oracle admin') ?

@wistb Hmm, I'm not sure. In my experience, the dbas are the developers.

also, the role of 'Oracle admin' is different from traditional, right ? in that, there is no schema, triggers, procedures that need admin's attention/approval

the role is limited to 'operations' only.

@wistb there will be an operations role on datomic

right. And, it is most likely handled by the product company (than the customer who bought the product)

In that sense, the number of "admin" resources the customer need to worry is only one.

but, because datomic is not document store, I probably cannot eliminate mongo.

(d/transact conn [{:my-attr/type-ref-to-may [{:other-entity 123}]}]) now works? There is docs about that?