Fork me on GitHub
Chris Bidler02:04:31

^^ I was able to resolve this. It wasn’t the CRR, but the initial “seed” copy missed a bunch of files somehow - not all of them, but many. Once I tracked down the missing key and saw that it was from November of 2016, it was pretty clear what the problem was. 😅


what is the exception?


Hi guys, I'm having a bit of trouble with Datomic monitoring. Specifically the TransactionMsec metric, in the online documentation, I see that the metric should have 3 statistics max, avg, and min but when I collect the metrics, I get 4 statistics: count, hi, lo, and sum. I can guess that count is the number of transactions in that frame but sum is a completely mystery to me since it's value is always higher than hi.


sum is the sum of all values over the past minute, hi and lo are the largest and smallest values over the past minute, respectively. count is the number of individual instances of that metrics


so you can get average by taking sum/`count`


Got it, thanks!


Hi guys Do I understand correctly that client library (datomic.client) gets all attention now (because of Datomic Cloud) and peer library will be eventually deprecated?


Whoa I certainly hope not!


no. peer will remain an active part of Datomic On-prem


Good to know, thanks for answering


@U05120CBV so you still believe that the peer model has advantages? or would you push new users towards the client model?


there are definitely use cases where the peer makes more sense. we’re working on options for solving some of those issues in Cloud

metal 4

The ease of use of Cloud and the fact that you can use Client with either Cloud or On-Prem makes it my recommendation in general, however


So cognitect positions client as preferred way?


if you’re getting started on a new project, yes i would suggest client, as it provides the most options. i wouldn’t suggest changing an existing application that already uses the peer


@U1V7K1YTZ My way of summarizing it would be that Peers give you expressive more power but also more operational constraints / challenges - you then need to see which of those matter to you


I agree with Val; The Client library is inherently more flexible and better suited to certain use cases (i.e. microservices)


it’s much lighter weight than peer


but there are definitely things you can do in peer that would be very challenging (or impossible) with client


Thanks again for answers!


is there a reason why a transaction would fail with (d/with db {:tx-data tx}) and work properly with d/transact? I'm using the client lib and this is the exception:


clojure.lang.ExceptionInfo: Datomic Client Exception {:cognitect.anomalies/category :cognitect.anomalies/incorrect, :datomic.client/http-result {:status nil, :headers nil, :body nil}}


@stijn can you provide the stack trace (the ex-info)


@stijn can you share the actual tx data here?


I'm about to implement something that's kind of like more sophisticated pull expressions. They allow excluding nested entities that do not match criteria, for example... possibly back references, even. 1) Does this sound like something else which exists? 2) Has anyone else wanted or needed this?


To back up, this is for computing dependencies between tasks which have an "input" pull and an "output" pull, as well as determining whether tree-like data satisfies an "output" pull.