cancel
Showing results for 
Search instead for 
Did you mean: 

@cap-js/sqlite $batch failing for all entries after the first

JWJ
Participant

Hello,

I'm trying out the new `@cap-js/sqlite` module by updating our software. We use Postman to insert test data and I found that our Postman $batch requests are now failing. The first request within the batch succeeds but all the following fail with "[cds] - SqliteError: database is locked". This didn't happen before switching from `sqlite3`. Could it be a bug or do I need to structure it differently? Is there a configuration option I need to toggle? Is there a better approach?

The query is `POST http://localhost:4004/odata/v4/entity/$batch`.

Headers:

Content-Type: application/json
Authorization: Basic c2FtOnNhbQ==
User-Agent: PostmanRuntime/7.32.3
Accept: */*
Postman-Token: 75a8b3cb-cc75-4884-b231-f82b97b5f812
Host: localhost:4004
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 3021<br>

Request body looks like this:

{
    "requests": [{
            "id": "Entity-0",
            "method": "POST",
            "url": "Entity",
            "headers": {
                "odata-version": "4.0",
                "content-type": "application/json;odata.metadata=minimal"
            },
            "body": { ... }
        }, {
            "id": "Entity-1",
            "method": "POST",
            "url": "Entity",
            "headers": {
                "odata-version": "4.0",
                "content-type": "application/json;odata.metadata=minimal"
            },
            "body": { ... }
        }, {
            "id": "Entity-2",
            "method": "POST",
            "url": "Entity",
            "headers": {
                "odata-version": "4.0",
                "content-type": "application/json;odata.metadata=minimal"
            },
            "body": { ... }
        }
    ]
}<br>
gregorw
Active Contributor
0 Kudos

I would suggest to check if an issue in https://github.com/cap-js/cds-dbs exists and create one there if not.

Accepted Solutions (0)

Answers (1)

Answers (1)

vansyckel
Advisor
Advisor

Hi Jay,

Opening an issue, as suggested by gregorw, is a good idea.

Workaround: add property atomicityGroup with the same value to each request, e.g., "atomicityGroup": "123". Then all POSTs share a transaction and cannot block each other. Without atomicity group (or "changeset") the requests run in parallel with separate transactions.

Best,
Sebastian