Replies: 4 comments 1 reply
-
I've been playing with this myself and following this conversation to hear a response from the maintainers on the roadmap for this. I'll also imagine you are asking for similar reasons that brought me to the docs on installing from a 3rd Party Repository. This works for my scenario, but it would be nice if I didn't have to do this manual step to host the Parquet extension that I think is widely used by DuckDB-WASM users. https://duckdb.org/docs/api/wasm/extensions.html#serving-extensions-from-a-third-party-repository |
Beta Was this translation helpful? Give feedback.
-
Initial plan was having parquet and JSON by default shipped in, then they become test-benches of sort for the extension logic, also given there are some underlying problems with keeping package size low. I am not opposed to having them in, unsure code-size how that can work (main wasm file is about 35MB pre compression, parquet stands at 1.9MB and json at 0.8MB), or whether it could be made opt-out. Another potential way would be having an easy way for whoever uses duckdb-wasm to bundle (in a build-time step) extensions of his choosing with the duckdb main wasm binary (while keeping other extensions from default location, whatever the default is). |
Beta Was this translation helpful? Give feedback.
-
Question is: would it have to be packaged in a single binary, or it would be fine to have some other way to specify (say via a config provided JS-side) the location of some additional extensions that can be provided via this preferential channel? Looking for feedback / use cases where extensions would be problematic. |
Beta Was this translation helpful? Give feedback.
-
This sounds like the solution I had in mind. I imagined the extensions could be included in the NPM package. You could choose to package this with your app or use an externally hosted copy which has its use cases, or not use it at all to reduce the overall amount of binary that needs to be sent to the browser. This would eliminate the logistics of keeping DuckDB-WASM in sync with the extension that you have to do now. |
Beta Was this translation helpful? Give feedback.
-
We upgraded to
1.28.1-dev99.0
but now duckdb-wasm seems to be trying to load Parquet extension from https://extensions.duckdb.org/duckdb-wasm/v0.9.2/wasm_eh/parquet.duckdb_extension.wasmThis is being blocked by the browser (I believe due to an existing CSP policy in the organization).
I would like to still have the newer version that supports extensions, but is there a way to get a distribution that has the parquet package in it?
Thanks
Beta Was this translation helpful? Give feedback.
All reactions