304f953710
* call ffi * remove duckdb dep * rename windmill_duckdb_ffi_internal * static lib * ci * back to dylib, bug isn't fixed in static * feature flag and copy dynamic lib * fix dynlib in docker * load libwindmill_duckdb_ffi_internal at runtime on usage * lazy static deadlocks * Cache dynamic library handles * update auto s3 path insert from editor bar * Fix duckdb S3 freezing worker because of blocking task in tokio async context * build dll windows GH workflow * try fix windows build * revert build.rs * nit fixes CI * Dockerfile update (not tested yet * build dev sh for duckdb lib * mistake * attach windmill_duckdb_ffi_internal.so artefact * rhel9 * docker fixes * fix dockerfile * better err msg * forgot lib prefix .so * add column_order * fix column_order
828 B
828 B
This crate is compiled separately because it causes nasty issues when compiled with the deno_core feature flag enabled (lib c++ interactions).
The main issue was : Errors in DuckDB always worked correctly, except when attached to a Ducklake and when the deno_core feature flag was set. For example:
ATTACH 'ducklake' AS dl; USE dl;
CREATE TABLE IF NOT EXISTS t (x string not null);
INSERT INTO t VALUES (NULL);
causes Constraint Error: NOT NULL constraint failed: t.x normally, but here we see Unknown exception in ExecutorTask::Execute. This opaque errors comes directly from the C++ DuckDB library : f99fed1e0b/src/parallel/executor_task.cpp (L58)
To solve this, we compile duckdb separately from the main backend crate and call it with FFI