Michael Kuhn

Instead of having to build dependencies locally etc., we could offer pre-built containers containing all dependencies and necessary tools. See https://code.visualstudio.com/docs/devcontainers/create-dev-container for an example.

We should add some explicit parallel tests for the different clients to make sure they work properly in a multi-threaded environment.

Since we already have one for MariaDB/MySQL, adding one for PostgreSQL should not be too hard. These also look interesting: - https://github.com/canonical/dqlite - https://github.com/rqlite/rqlite - https://github.com/cockroachdb/cockroach

We should make `julea-kv` and `julea-db` use the same code base. `julea-db` currently has more features and is better maintained.

It seems that `H5VL_julea_db_dataset_set_info` always sets a default round robin distribution, even for existing datasets. This causes object chunks to be mixed up if the (randomly chosen) starting server is...

See https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/

We are currently using LeakSanitizer (via AddressSanitizer) when running the tests (but ignore memory leaks). It would probably be best to check for memory leaks separately and also include Valgrind.

Our HDF5 tests sometimes hang before/in `/hdf5/dataset/write_read_selection`: ``` 1/1 julea-test RUNNING >>> MALLOC_PERTURB_=210 /home/runner/work/julea/julea/bld/julea-test -r /hdf5 ▶ 1/1 /hdf5/read_write OK ▶ 1/1 /hdf5/dataset/create OK ▶ 1/1 /hdf5/dataset/write OK ▶ 1/1...

It seems that the `GError` passed to, for example, `j_db_schema_delete` is passed all the way through to `j_backend_db_schema_delete`. If the original `GError` is freed in the meantime (which happens for...

We should also test applications that use JULEA (for example, Enzo on top of our HDF5 plugins).