Json api v1/create multiple records embedded in json file

Hey Daml’ers

I am experimenting with a postman json record to submit to the daml json-api v1/create message

I want to submit multiple records into one json file

[
    {
        "templateId": "IOU:IOU",
        "payload": {
            "field1": "Content1",
             ...
         }
    },
    {
        "templateId": "IOU:IOU",
        "payload": {
            "field1": "Content1",
             ...
         }
    },
]

This gives the following daml error

{
    "errors": [
        "JsonError: DomainJsonDecoder_decodeCreateCommand JsonReaderError. Cannot read JSON: <[{\"payload\":   <More content here>
,\"templateId\":\"IOU:IOU\"}]>. Cause: spray.json.DeserializationException: Object expected in field 'templateId'"
    ],
    "status": 400
}

I noticed from documentation you can do multiple records for v1/fetch, but am wondering if it is possible with v1/create

Any thoughts ?

2 Likes

I had a better look at the docs and I don’t think you can issue multiple commands in a single call. Looking at the docs it doesn’t appear that you can specify multiple contracts using /v1/fetch (docs) but I may be missing something.

1 Like

I apologize…it was v1/query… take a look at the section
https://docs.daml.com/json-api/index.html#contracts-query-stream

it shows

Multiple queries may be specified in an array, for overlapping or different sets of template IDs:


[
    {"templateIds": ["Iou:Iou"], "query": {"amount": {"%lte": 50}}},
    {"templateIds": ["Iou:Iou"], "query": {"amount": {"%gt": 50}}},
    {"templateIds": ["Iou:Iou"]}
]
1 Like

Oh, yes, definitely, you can issue multiple queries in a single request.

1 Like

So you are saying it can be done for v1/create ? How ?

No, I’m saying you were right about /v1/query, apologies for the miscommunication.

1 Like

Ok. Thanks. This feature may be a nice to have for the future.

I will create a Postman Library then instead.
Thanks for the clarification.

2 Likes

There is an important difference between what multi-command submissions on the gRPC API provide you with and what a hypothetical matching functionality on the JSON API could provide and what handling this on the client side via a postman library or whatever else provides:

Multi-command submissions on the gRPC API are transactional meaning they result in a single transaction or fail. If you do this on the client-side you will produce one transaction per command.

This has a few implications. Most importantly you loose atomicity by doing it on the client-side. Second, a single transaction with two creates is much cheaper for the ledger than two transactions each with one create. (At some point very large transactions can cause issues but we’re talking about thousands of actions in a single transaction here).

So what do you do if you use the JSON API and you need atomicity or the better performance? Luckily, you don’t need a special endpoint for this. You can handle this via createAndExercise. Here is a simple example of how you can use createAndExercise for the multi-create usecase you described:

template Helper
  with
    p : Party
  where
    signatory p
    choice CreateN : [ContractId T]
      with ts: [T]
      controller p
      do mapA create ts

test = script do
  p <- allocateParty "p"
  submit p $ createAndExerciseCmd (Helper p) (CreateN [T with …, T with …])
5 Likes