No, exposing an interface to SQLite3 embedded in FTL is nothing else than a convenience feature (user won't have to install sqlite3 as extra package). There is nothing else in this and no transition is needed. The main driver for this was the new command UPDATE FROM:
UPDATE-FROM is supported beginning in SQLite version 3.33.0 (2020-08-14)
It's take a long time until we could use it in our scripts and we'd always have to add fallback in case users still run this Pi-holes on stretch, etc. which will likely never receive this update.
[2021-01-19 16:16:33.850 16793M] domain_in_list("detectportal.firefox.com", 0x73228aa8, whitelist): Database is busy, assuming domain is NOT on list
[2021-01-19 16:16:33.851 16793M] domain_in_list("detectportal.firefox.com", 0x73229408, blacklist): Database is busy, assuming domain is NOT on list
[2021-01-19 16:16:33.851 16793M] domain_in_list("detectportal.firefox.com", 0x73228148, gravity): Database is busy, assuming domain is NOT on list
then be considered as an error which needs to be fixed by development or works as designed?
It depends. Are you using tools to access the database (also like the long-term tool on the dashboard)?
If yes, then this is expected. If not, then we'd have to find out why your database is busy:
Do these messages also show up after restarting pihole-FTL?
Do these messages also show up after restarting the device?
(hopefully terminating any possible third-party)
Does sudo -u pihole sqlite3 /etc/pihole/gravity.db "BEGIN EXCLUSIVE;COMMIT" work or does it complain about a database lock/busy as well? If so, does it do the same when you stop pihole-FTL and try this again?
sudo -u pihole sqlite3 /etc/pihole/gravity.db "BEGIN EXCLUSIVE;COMMIT"
gives no reaction on the command prompt, any other place to check for an expected result? - where to check and what should the command do?
the db busy are not showing up during normal op, mainly while doing pihole upgrades or restarts
Okay, that is expected, sorry I should have said that. This command locks the database exclusively and releases the lock immediately. It would have only complained if the database would have been in a busy state.
This may mean that your CPU is a lot faster than your disk and that the (intended) concurrency of FTL hits a few mutiple-access-at-once spots during startup. This is not a problem as FTL expects such things and handles them (hence, the log message saying what it did).
Yes, the error can be safely ignored. I will nevertheless keep an eye open and fix anything odd I encounter. Pi-hole v6.0 development is in full swing and it'll do a few things differently. We'll have an extended beta period before any release and maybe the two of you would enjoy participating.