couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Pluggable Storage Engine API
Date Thu, 23 Jun 2016 19:29:29 GMT
Hi Mayya,

The reason that the storage engine test suite uses
test_engin_util:init_engine() is because its pulling the engine to
test from the test configuration. If you check out the test suite for
couch_ngen [1] you'll see that its just using a single line to
instantiate all tests for the storage engines. The reason these are
written this way is so that every storage engine that is implemented
can re-use the same test suite to ensure that the tested behavior is
correct. This is important so that we're sure that every test engine
can pass the specified behavior. And it also means that each storage
engine doesn't have to copy those test definitions and make sure
they're up to date between releases and so on.

The couch_db:open_int/2 interface allows for specifying the engine by
config name but in a test suite that config may or may not exist. Not
only that but the test you had defined also don't get picked up by
test_engine_util:create_tests/1 which means that any non-default
storage engine will miss out on the tests as well.


On Thu, Jun 23, 2016 at 11:59 AM, Mayya Sharipova <> wrote:
> Hi Paul,
> continuing our discussion here. You said that I need to configure the engine I open in
the tests:
> {ok, Db} = couch_db:open_int(DbName, []),
> #db{
>      engine = {Engine, St}
> } = Db,
> What do you mean by configuration?  Is it the initialization you did in your tests:
> {ok, Engine, St1} = test_engine_util:init_engine(),
> If by configuration we mean initialization, I guess the engine gets initialized while
we are opening a db: couch_db:open_int(DbName, []),
> in couch_db_updater:
> {ok, EngineState} = couch_db_engine:init(Engine, FilePath, Options).

View raw message