This issue lists the modifications to be done to create a Bedrock module for SDSKV.
[x] Follow the example here or here and the header here or here to implement a sdskv-bedrock.c(pp) file compiled into a libsdskv-bedrock.so library;
[x] Add the proper --enable-bedrock option in configure to look for the Bedrock header. There is no need to link libsdskv-bedrock.so with libbedrock-server.so, however it should be linked against libsdskv-server.so and libsdskv-client.so.
[ ] Add a +bedrock option in SDSKV's spack package (I suggest turning it on by default) to enable building the Bedrock module.
[x] Currently the SDSKV provider instantiates a REMI client and a REMI provider. These dependencies should be injected into the provider via an API rather than instantiated by the provider, i.e., there should be a function sdskv_provider_set_remi(...) in the SDSKV server library, that takes a SDSKV provider, a REMI provider and REMI client. (Matthieu can take care of that once the rest is done).
[x] We should be able to provide a JSON configuration when initializing the SDSKV provider. This can be done either by changing the signature of the sdskv_provider_register function (passing a structure like in Margo, containing the JSON string, the pool, and optional dependencies such as the REMI client and provider. The JSON configuration should contain provider-specific configurations, as well as a "databases" array listing databases we want to open or create upon registering the provider.
[x] We also need an SDSKV provider to have a function to get a JSON object out such that passing this JSON object as config back to SDSKV will set SDSKV into exactly the same state as the one that generated the config (i.e. exact same parameters, exact same databases opened, etc.).
[x] Margo now provides logging facility and Bedrock dependency-injects a logger in it, so if SDSKV were to use Margo's logging functions, its logs would integrate nicely with Bedrock's and Margo's. (see here.
[ ] It would be nice to have an admin library as well, which would enable creating and opening databases remotely (right now this can only be done by calling server-side functions).
[x] There is a little difficult with SDSKV, which is the support for comparison functions. These functions are set into a provider using sdskv_provider_add_comparison_function, which takes a function pointer, hence is not ideal in the context of a JSON-based configuration. I would suggest adding a sdskv_provider_find_comparison_function(const char* library, const char* function_name) which would use dlopen to lookup for the function in the specified library. This would allow us to have something like this in the JSON conparator for a database: { "comparator" : { "library" : "libsomething.so", "name" : "my_comparator" }}, allowing the comparison function to be provided using a path to a library.
roblatham00
commented
3 years ago
Originally opened by @mdorier on xgitlab
This issue lists the modifications to be done to create a Bedrock module for SDSKV.
--enable-bedrockoption in configure to look for the Bedrock header. There is no need to link libsdskv-bedrock.so with libbedrock-server.so, however it should be linked against libsdskv-server.so and libsdskv-client.so.+bedrockoption in SDSKV's spack package (I suggest turning it on by default) to enable building the Bedrock module.sdskv_provider_set_remi(...)in the SDSKV server library, that takes a SDSKV provider, a REMI provider and REMI client. (Matthieu can take care of that once the rest is done).sdskv_provider_registerfunction (passing a structure like in Margo, containing the JSON string, the pool, and optional dependencies such as the REMI client and provider. The JSON configuration should contain provider-specific configurations, as well as a "databases" array listing databases we want to open or create upon registering the provider.sdskv_provider_add_comparison_function, which takes a function pointer, hence is not ideal in the context of a JSON-based configuration. I would suggest adding asdskv_provider_find_comparison_function(const char* library, const char* function_name)which would usedlopento lookup for the function in the specified library. This would allow us to have something like this in the JSON conparator for a database:{ "comparator" : { "library" : "libsomething.so", "name" : "my_comparator" }}, allowing the comparison function to be provided using a path to a library.