While prescanning a large database, minetestmapper may keep the database
locked for too long, causing minetest to complain, and even bail out
sometimes. Minetest will print warnings like:
SQLite3 database has been locked for <duration>
The new option --sqlite3-limit-prescan-query-size limits the number
of records queried from the database in a single query, thus limiting
the duration of the lock.
If minetest kept the database locked for 1 second or more, *and* if
the database was modified in that time, minetestmapper will issue a warning,
and suggest using --sqlite3-limit-prescan-query-size.
If mapping while minetest is running and modifying blocks, modified
blocks queried by RowID, would not be found by SQLite3. Querying
by I64 exclusively did not cause such behavior.
i.e. allow minetestmapper to query the database for a list of
blocks in a specific range (corresponding to the requested geometry),
instead of always obtaining a full list off all blocks.
As postgresql is the only database which supports this efficiently,
this option is only effective for postgresql.
As tests using --sqlite-cacheworldrow showed a consistently
lower performance than without, this option was effectively
disabled. It is still recognised for compatibility, but
it may be removed some time in the future.
Added the option to bulk load and cache entire world rows at
a time when using sqlite. Caching is implemented in the
database class this time around.
Enabled using --sqlite-cacheworldrow on the command line.
This is essentially re-introduces the database access strategy
that was used originally, but as an option.
Currently, one block is read at a time from the database.
The original behavior was to read and cache one entire world
row at a time, irrespective of whether or not only a (small)
subsection of the world was being mapped.
Under some circumstances, in particular if the entire world is
mapped or a relatively large percentage of it (blocks-wise), the
bulk loading and caching may outperform the one-by-one strategy,
even though it usually loads many more blocks than are actually
needed.
It seems that leveldb won't benefit from any kind of caching or
bulk loading of blocks, so none was implemented.
Leveldb does compile now. Still not tested on a database :-(
Improved the database statistics (printed with --verbose).
