We put this new schema update into the main line and change the
versions of the schema updates which are currently only available
in dev builds. The schemas need to be chronological therefore we
also need to rename the file numbers.
Here, we make the sql query option params (batch size and pagination
size) configurable. The defaults for SQLite vs Postgres are still the
same but will be changed in an upcoming commit.
We rename this helper along the config types & helper types for it
because the word "page" is used more often in the context of paging
through results using an offset and limit whereas this helper is
specifically used to split up the slice in queries of the form
"WHERE x in []slice". We do this rename so that there is mimimal
confusion in contexts where we use batching along with actual paging.
The config struct is also renamed to QueryConfig in preparation for it
holding more config options.
This commit adds a basic itest that is run under the `test_native_sql`
flag. It tests that the migration is idempotent and that the node cant
be restarted without the `db.use-native-sql` flag once the graph
migration has been run.
This commit plugs in the graph kvdb-to-sql migration for builds
containing the `test_native_sql` tag. This will allow us to perform
local tests and write itests for the migration without exposing it to
the production release build.
In this commit, a new `test_native_sql` build flag is defined. If this
build flag is used along with the `--use-native-sql` config option, then
the SQLStore implementation of the graphdb.V1Store will be initialised.
This is then used to run our itest suite against the new SQLStore graph
implementation.
NOTE that this only works for new nodes currently - the migration from
kv-to-sql is yet to be implemeneted.
