This PR adds incipient support for wasm_udf, as defined in #1653. A new feature is added, so compile with --features wasm, if you want to test it.

I used Wasmtime as the wasm engine to run the wasm code. Wasmer or WasmEdge or some other engine can be chosen as well, with not many modifications, in theory.

The most important part is the type conversion from Dozer types to wasm types, which natively are very few (only i64 and f64 could be used for now). Wasm doesn’t natively support i128, and Dozer does not support i32, so there were not many type that matched.

More types can of course be added (Boolean for example is trivial to add, even if it wastes an entire i32). For composite types, like String or Text, binding generation support has to be added.

I could not find the parsing of the dozer-config.yml, so I was inspired by the python_udf module to use environment variables. You can define DOZER_WASM_UDF to point to a .wasm file with the exported functions.

Testplan:

An AssemblyScript example has been added to ./dozer-tests/wasm_udf/assemblyscript. The simples way to test the feature is to use the dozer-samples sql join test.

Change the sql to include a simple wasm_udf call:

sql: |
  SELECT t.tpep_pickup_datetime AS pickup_time, z.Zone AS zone, wasm_addf(9.5, 10.7, 'float') as WASM
  INTO pickup
  FROM trips t JOIN taxi_zone_lookup z ON t.PULocationID = z.LocationID;

Follow the rest of the instructions in that example.

To build the AssemblyScript that contains the wasm_addf function:

cd ./dozer-tests/wasm_udf/assemblyscript
npm install && npm run asbuild

The module is now at ./dozer-tests/wasm_udf/assemblyscript/build/debug.wasm. Set DOZER_WASM_UDF before you run the example:

DOZER_WASM_UDF=./path/to/debug.wasm dozer

/claim #1653