What are the recommended ways to test a transaction function with datomic cloud? I can see that a traditional fixture approach will work against a datmoic cloud service (create-database, add schema, add data, run tests, drop database). Can't see how generative testing could work because of the db parameter but I do see we can treat that as static at least (ref https://docs.datomic.com/cloud/transactions/transaction-functions.html#testing). Feels like using datomic free in-mem would be faster but I think that doesn't have the cloud-api (likely premature optimisation in that thought).

Instead of trying to interpret/validate the data returned I guess I could be observing the normalised data associated with the change it makes on the database via the Log API.

sorry if someone already asked this but…the result of a datomic client query is a vector of vector tuples. in the old (peer) api it was a set of vector tuples. is this deliberate? the reason I ask is because the docs https://docs.datomic.com/cloud/query/query-executing.html show two behaviours - first a set and then a vector. which is correct or is there some way to control this?

I could imagine this being related to the new :limit and :offset features (presumably for pagination) although that would also imply some kind of “order by” feature as well but I can’t find docs on using these for pagination

I found the docs for :limit and :offset https://docs.datomic.com/cloud/client/client-api.html although I’m still unsure about the lack of “order-by” like behaviour when using these features. Is it just arbitrary?

so, in summary: 1/ is the set result here a doc bug? https://docs.datomic.com/cloud/query/query-executing.html and 2/ when paginating, is there an implied ordering or can we control this now?

another possible doc bug? : should the :server-type be :cloud in the “Connect and use Datomic” section (instead of :ion)

I suspect a bug in the client api as well. it doesn’t mention :ion here (throw (impl/incorrect ":server-type must be :cloud, :peer-server, or :local")))

I can’t see any change in behaviour between :cloud and :ion. is there any difference?

Released Datomock v0.2.2. This solves bugs with Datomock's Log implementation, which failed to accept nil, Dates and tx-entids for txRange bounds. https://github.com/vvvvalvalval/datomock

Perhaps a typo in the Ions Tutorial. In the Deploy section it gives an example of using curl to make sure everything is okay:

curl https://$(obfuscated-name). -d :hat

curl https://$(obfuscated-name). -d :hat

Clearly that's not quiet right but it works.

hi @steveb8n Query is documented to return a collection of tuples: https://docs.datomic.com/client-api/datomic.client.api.html#var-q, so your consuming code should not know/care about sets vs vectors. There is no "order by" in query (yet).

hi @olivergeorge You can generate db values by picking from a set of premade example values, and those example values do not need to be constructed every time you run the test. Why not construct fixture dbs once when you write a test, give them good db-names (db-in-state-A, db-in-state-B)?

I'll give that a try. Thanks.

@olivergeorge what does your tx fn do?

At this stage I'm doing simple things. But thinking ahead to more complex systems. Still lots to learn.

Thanks @stuarthalloway for the clarification

any advice/strategies on env config/parameterization for ions? I know we can obviously just stick the info in datomic itself

The “as a standalone Clojure API” link at the very top of https://docs.datomic.com/on-prem/pull.html is broken

any preferences where to report this?

@eoliphant I recommend using AWS Systems Manager parameter store. Hm, maybe Datomic should have a feature making that easier... 🙂

yes, that’s definitely more in line with what I was thinking 🙂

@kommen thanks - i’ll fix it

Hmm... I gather that datomic doesn't store duplicate values. But could it be done? Usecase: I want to store the last n dice rolls for one of my players, but duplicate values should still count. Currently I'm just using the following schema:

{:db/ident :player/last-rolls
              :db/valueType :db.type/long
              :db/cardinality :db.cardinality/many
              :db/doc "The last couple of dice rolls for this player"}

Hey @rhansen, you could change :db/valueType to :db.type/ref then create an entity to represent a roll, including a timestamp on the entity.

you could also encode the value

what do you mean “encode the value”?

cardinality one, the value is an encoding of multiple values

to datomic it looks like one value

your application decodes it to get many values

Interesting.

I'll probably go the ref route, thanks for your help 🙂

Do you have an example of this? Do you mean encode as a series of bytes or a string? Just looking for some clarity here. Seems like a workaround to encode an ordered collection, am I right?

that is exactly what it is

specifics may vary; bytes, strings, bignums, whatever

the point is only that datomic doesn't see into the value; because it's a blob to datomic you can store whatever you want in it that datomic couldn't represent natively

or could represent but too inefficiently for your use case

e.g. json array in a string

as well as an edn string too I suppose. Neat. That may change the way I model a schema today. I’ll give it a shot.

thanks

can I confirm something: the scalar query using . is not supported in Client/Cloud e.g. ’[:find ?movie-title . :in $ :where [?movie :movie/title ?movie-title]]

getting a single result was pretty useful in the peer api. it’s no biggie to call ffirst on the result in client but I just wanted to confirm that this feature has been removed