segfault when recovering database with UPS_TYPE_CUSTOM keys about upscaledb HOT 3 CLOSED

Option 1: split the recovery operation into a new API function (ups_env_recover) and deprecate UPS_AUTO_RECOVERY.
-> requires updates for the wrapper APIs, remote API...

Option 2: somehow store the callback function in the ups_parameter_t structure -> but this is super ugly

Option 3: come up with another hack -> even more ugly

from upscaledb.

About second option: databases might use various callbacks. But this concept might be modified to introduce new callback. As probably most developers know what they store in particular databases this callback might be used to temporary set compare function for known id databases during recover. Anyway, it's still ugly but probably more flexible.

Introducing new dedicated function for recovery also need to handle possible various compare function for databases in environment.

from upscaledb.

I found a way for option 2 to be less ugly.

Callbacks are registered globally under a "name" (this can happen prior to opening or creating the Environment):

ups_register_compare_callback(const char *name, ups_compare_callback_func cb);

When creating the database, the name is specified as a parameter:

ups_parameter_t db_create_params[] = {
    {UPS_KEY_TYPE, UPS_TYPE_CUSTOM},
    {UPS_KEY_COMPARE_CALLBACK, (uint64_t)"int128compare"},
    ...
};

(I use a similar pattern of registering global callbacks for a different set of functions which are not yet released.)

When opening the database, it is not required to specify the callback name since the name is persisted.

However, it is not trivial to persist the name. I'll try to work something out.

from upscaledb.