Reorganize storages API and make BaseStorage public

blocked by #2938

Motivation

Currently, BaseStorage is private to users, and it is not expected that users will inherit BaseStorage and implement new storage classes. Also, even if you actually try to implement it, there are many methods that must be implemented, and the requirements that each method must satisfy are unclear. So, there are high hurdles for general users to implement them. By reorganizing the storages API, we want to reduce the number of methods that must be implemented and clarify the requirements that each method must satisfy. After that, I want to make BaseStorage public if necessary.

Description

The storage API will be reorganized from the following viewpoints.

• Reduce the number of methods that must be implemented
• Clarify the requirements that each method must satisfy

After that, considering the pros / cons of making BaseStorage public, and if pros is stronger, make it public.

TODOs

• Redesine storages API to reduce their methods
• Reduce the number of methods that must be implemented
• Clarify the requirements that each method must satisfy
• Make BaseStorage public if needed

Details actions

Redesine storages API to reduce their methods

The following methods can be removed from the APIs:

• set_trial_values and set_trial_state https://github.com/optuna/optuna/pull/3323
• Add deprecation to get_n_trials.

Reduce the number of methods that must be implemented

get_trial_xxx

We can provide the default implementation in BaseStorage using get_trial. c.f. https://github.com/optuna/optuna/pull/2994

• get_trial_number_from_id https://github.com/optuna/optuna/pull/3338
• get_trial_param https://github.com/optuna/optuna/pull/3338
• get_trial_params

set_trial_xxx

Need discussion

get_study_xxx

Need discussion

set_study_xxx

Need discussion

[keisuke-umezawa]

The committers concluded that we need to do fundamental changes to the storages API before making it public. e.g.

• Currently, the storages have two responsibility, one is for CRUD operations and the other is for transaction management. It might be divided into two layers.
• The storages have optional features such as cache and heartbeat. They might be separated from mandatory storages APIs.

Those are examples we need to find solutions before making it public, and we estimated that it would be difficult to complete it by v3 release. So, we will postpone it later.

[masap]

I think we should merge set_trial_state and set_trial_values.

@not522 I could reproduce the issue with some delay and fixed the issue with #3323. Does this fit with your idea?