OPFS support + Error: Failed to commit: File is not opened in write mode

[dheerajawale-svg]

What happens?

I added config as below:

const config = {
    query: {
      castBigIntToDouble: true,
    },
    path: `opfs://test1.db`, // Use OPFS path for the DuckDB database
    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,
  }

I am loading the file from C drive using standard file dialog:

<input
          type="file"
          ref={fileInputRef}
          style={{ display: 'none' }}
          onChange={handleFileChange}
        />

File selection code:

const handleFileChange = async (event) => {
    const file = event.target.files[0];
    if (file) {
      await loadData(file);
    }
  };

When I open file and execute command using below code it throws the error:

const tempFile = getTempFilename() + ".parquet";
      duckDbInstance.registerFileHandle(tempFile, file,
        duckdb.DuckDBDataProtocol.BROWSER_FILEREADER,
        true,);
      
      const conn1 = await duckDbInstance.connect();

      var createQuery = `CREATE TABLE '${tableName}' AS SELECT * FROM '${tempFile}'`;
      await conn1.query(createQuery);
      await conn1.close();
      await duckDbInstance.dropFile(tempFile);

PFA attached error log.

error.txt

Question: Is it correct? does duckdb handles loading file into OPFS internally?

To Reproduce

• Using ReactJs app
• In the duckdb config add this:

const config = {
    query: {
      castBigIntToDouble: true,
    },
    path: `opfs://test1.db`, // Use OPFS path for the DuckDB database
    accessMode: duckdb.DuckDBAccessMode.READ_WRITE,
  }

• Open and load a parquet file using 'registerFileBuffer' or 'registerFileHandle'
• Run CREATE Table query by opening connection to duckdb

Browser/Environment:

Version 135.0.7049.115 (Official Build) (64-bit)

Device:

Thinkpad laptop, Windows 11

DuckDB-Wasm Version:

"@duckdb/duckdb-wasm": "^1.29.1-dev132.0"

DuckDB-Wasm Deployment:

bundled

Full Name:

Dheeraj Awale

Affiliation:

natus

[booandrew]

Hi! I’ve already left a comment in this repository regarding a similar issue.
In short, we came up with a workaround: first, we run a dummy CREATE OR REPLACE TABLE statement, followed by a DROP TABLE query. After that, the accessMode error no longer occurs.
You can read more about it here: #1962 (comment)