Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Cloud by
edited by

Is there absolutely no way to access the peer api on datomic cloud?

My thinking is that, conceptually, since it uses clients, that implies that peer servers do exist.

I realise that light horizontal scaling is the point in DC, but the peer api, and in particular d/with I'm finding important to allow test scaffolds for transaction functions.

So the thought here is it would be nice to be able to access the richer peer api just for one off tasks, such as managing schema or even here making speculative databases so one can create a test scaffold to test a more complex transaction function.

I don't know what the test scaffold story is with DC or if there is one. Bit of a dark area on the map for me at the moment so any suggestions would be appreciated.

I guess one last-resort option is to develop using Pro and test transaction functions that way. Then copy them over to DC. I have found though that in a previous iteration trying to think about Pro and Cloud at the same time as designing for your domain is something I would want to avoid where possible.

Update: I've just realised that the client api does actually include d/with, but I'll leave the question up anyway, in case anyone has any related thoughts they'd like to share.

Further Update: looking back at my initial inept attempts to build a datomic system and schema which utilised transaction functions to avoid race conditions given a complex content hierarchy in the domain I am modelling, it looks like the reason I felt forced to use the Peer API and not Client, for those Database Functions, was the absence of d/function in the Client API. I wonder if Client API actually is fully capable in terms of installing and testing database functions, but that wasn't clear to me at the time. So much is required to be able to develop in Datomic. It might be that my missing a little detail of Clojure/Java design (an easy syntactic alternative to d/function?) ended up pushing my design decision in an unnecessary direction.
I suppose the answer may be, re. DB functions - "Client API yes", "Cloud no"?
(Illustrating the point that it is best not to try to think about Pro and Cloud at the same time...)

Remaining question: I'm finding it very difficult to find out what the difference is between d/function on the peer API, vs. use of the #db/fn literal. Cannot locate an explanation in the docs. GPT is telling me the latter is for an inline database function which will not be installed, whereas d/function is for installing the fn into the database, but it I know it could be hallucinating in such a case.

1 Answer

+1 vote

Hi Mike!

The peer api is not usable in Cloud, but after thinking about your situation I have a few points.

  1. The client api has d/with: https://docs.datomic.com/client-api/datomic.client.api.html#var-with
  2. I would recommend doing this kind of testing using Datomic local. https://docs.datomic.com/cloud/datomic-local.html. (added benefit you can actually import your DB and test against it with import-cloud + utilize an in-memory DB locally).

Does that cover your need for testing in Cloud?

All that being said, I have captured your question and use case here for our on-going consideration of apis for Cloud/Pro.


Thanks Jaret!

Yes the testing on DC looks covered now, now that I know d/with exists.  Local will help too. Merci.

But any suggestions on the following would be much appreciated if you had any thoughts! -

Would you generally recommend the use of Classpath functions over installed Database functions (when using Pro) nowadays, given that that is the only option on Cloud?    

The thinking being that learning one way to manage transaction functions is sufficient (I refer to the code and devops required), and so we may as well use a pattern on Pro which is also applicable to Cloud.

i.e. I'm wondering if the two methods are equally convenient and capable down the line.