Somehow a user ended up with duplicate data preventing creation of the
new unique index needed for UPSERT (see 3ec48555b773).
This should eventually self-heal #1918 if the duplicate data is replaced
by the older DELETE + INSERT method.
Without any index at all, it will be slower.
This is meant as a way to diagnose e.g. issues creating indices.
It would have been nice to capture e.g. PostgreSQL notices, but LuaDBI
would need support for this first, see https://github.com/mwild1/luadbi/issues/62
SQLCipher v3.4.1 (the version in Debian 12) is based on SQLite3 v3.15.2,
while UPSERT support was introduced in SQLite3 v3.24.0
This check was not needed before because we v3.24.0 has not been in a
version of Debian we support for a long, long time.
Note however that SQLCipher databases are not compatible across major
versions, upgrading from v3.x to v4.x requires executing a migration.
Attempts at making `prosodyctl mod_storage_sql upgrade` perform such a
migration has not been successful.
Executing the following in the `sqlcipher` tool should do the migration:
PRAGMA key = '<key material>';
PRAGMA cipher_migrate;
The word 'error' anywhere, especially in harmless debug messages, are
too often interpreted as fatal errors my some users, so best avoid that
word. These look too scary as it is, being tracebacks.
Fixes `prosodyctl adduser` etc.
Prior to d580e6a57cbb the line did nothing.
Sometimes storage in the prosodyctl context does cause weirdness, as it
is not in a host context, but rather a variant of global.
The ORDER BY and LIMIT clauses are not needed and don't even make much
sense. This part was most likely a leftover from the :find method.
Tested with sqlite and postgres 14
There's no 'prosody.prosodyctl' property other than this one, introduced
in 6216743c188c in 2015.
Guessing that the intent was to skip this when running as a prosodyctl
command. The module.command code does its own version of this
initialization, so this seems likely.
Thanks raja for noticing
Many of these fall into a few categories:
- util.cache size, must be >= 1
- byte or item counts that logically can't be negative
- port numbers that should be in 1..0xffff
No point in doing this expensive O(n) query if the result is not used
for anything.
Will still cache the total item count if an explicit query for this is
performed, then try to keep it updated with new items added. Will likely
forget eventually tho.
Currently limited to SQLite3 for lack of testing on other databases.
Adds a migration to replace the non-UNIQUE prosody_index, renaming it
prosody_unique_index since ALTER INDEX does not seem to be portable.
Fixes
Error in SQL transaction: Error executing statement parameters: ERROR: invalid input syntax for integer
This was handled for INSERT in 9524bb7f3944 but not SELECT.
Kim Alvefur