Only find-rel elements are allowed in client find-spec

More peer vs client; again from clojarians:

Conversation from slack

I have a syntax question. This is working:

(d/q '[:find (pull ?e [*])
       :where [?e :team/id]] db)

This is not, and is throwing Exception

(d/q '[:find [(pull ?e [*]) ...]
       :where [?e :team/id]] db)

Exception

ExceptionInfo Only find-rel elements are allowed in client find-spec

I’m using datomic-pro-0.9.5661

marshall14:04:01

Client only supports find rel https://docs.datomic.com/cloud/query/query-data-reference.html#find-specs

marshall14:04:20

Peer has additional options for find spec https://docs.datomic.com/on-prem/query.html#find-specifications

brett14:04:04

All I changed is the binding form. I see it in both links you sent.

marshall14:04:01

The client only supports the find-rel form. You can use the other binding forms for inputs, but not in the find specification

Summary

Datomic client does not support :find [?x] but does support :find ?x

:db.error/not-an-entity Unable to resolve entity: :db/index

When working with Datomic Ions, I wanted to use :db/index on an attribute but got this error:

:db.error/not-an-entity Unable to resolve entity: :db/index

Using the magic of Google I came across this tidbit:

robert.mather.rmm00:11:22

On Datomic Ions Solo, I'm getting an error Unable to resolve entity: :db/index when trying to transact schema

robert.mather.rmm00:11:30

oh, is :db/index not supported on Datomic Cloud?

robert.mather.rmm00:11:12

I guess fulltext indexes aren't either...

henrik05:11:22

Alas, no. And be careful with large strings as well.

Summary

It appears that :db/index and :db/fulltext are not support on Datomic Cloud.  The only documentation for this feature is in a slack log from November 2018.

https://docs.datomic.com/cloud/schema/schema-reference.html
https://docs.datomic.com/cloud/query/raw-index-access.html

Getting a stack overflow running datomic Ion cast in cider

I was getting a StackOverflowError running this in CIDER while developing with Datomic Ions


For some reason the output stream created ends up being referential with the nrepl PrintStream implementation. Changing it from :stdout to :stderr seems to solve the problem:

Which Clojure test runner to use?

Photo by Genaro Servín from Pexels

Clojure has a built in test framework which works very well and for most of my Clojure experience it has done the job, until yesterday.  As part of a new project I needed to integrate with Bitbucket Pipeline, specifically I needed to run my unit tests and have the build fail on a failed test and report which test failed.  Bitbucket supports this integration.

The standard way to do this is to have the test runner create a XUnit compatible XML file and have the CI tool consume this file to produce the reports.  Unfortunately, the junit.xml file created by the default Clojure test runner creates a junit.xml that does not follow the spec and Bitbucket doesn't report which tests failed.

After some research, I found that Kaocha does a much better job of creating a junit.xml that Bitbucket Pipeline can grok.  In addition, it also supports code coverage which is a great bonus.

Here is the stanza for deps.edn to make it work:

Datomic Ions: lget does not exist

Photo by Matej from Pexels

I keep running into this exception when running Clojure in on AWS using Datomic Ions:

{ "Type": "java.lang.IllegalAccessError", "Message": "lget does not exist", "At": [ "clojure.core$refer", "invokeStatic", "core.clj", 4249 ] }

 The cause for this error seems to be that the code is trying to use either the Datomic Peer API or the wrong Datomic Client API implementation.  I am using the datomic-client-memdb for testing and if the code tries to use it on AWS, you will get that error.  Similarly, if the code tries to use the Peer library from a Datomic Ion, it will get this same error.

The problem arises from older code trying at runtime to determine if the Peer or Client API is being used.  The ways this used to be determined seem to no longer work and so the code picks the Peer when it should be the Client.

So far I have not found any code that will correctly figure out which API is being used.