Workaround Qt 4 QSqlQuery::bindValue() not handling duplicate
parameter names by giving every duplicated parameter a unique name.
Qt 5 handles this as one expects, so this doesn't need forward-ported
to 0.14/master where Qt 4 support has been dropped.
Applies to SQLite and PostgreSQL.
Note: PostgreSQL prepared statements properly handle repeated "$"
parameters, so there's no need to modify those.
Test case for prepared statements:
> PREPARE qcore_test_var
AS SELECT * FROM buffer WHERE bufferid = $1 AND userid = $1
AND networkid = $1;
> EXECUTE qcore_test_var(1);
Gives a result if bufferid = userid = networkid = 1 exists.
Credit to @justJanne for finding the root cause of the issue, and
suggesting the fix, and to 'galfwender' and @darkstar for reporting.
Deduplicate code by moving LogEntry formatting into a separate
function, LogEntry::toString(), which applies timestamps and the log
level string.
Fix client Debug Log dialog to print log level using this new function.
Modify msgWithTime() to use this new function, too.
5f771f4...
by
=?utf-8?q?Wolfgang_M=C3=BCller?= <email address hidden>
logger: Make output to syslog nicer
Resolve the level string in msgWithTime. This means that the log
level string is included in logs to files and stdout even if syslog
output is enabled.
Resolve the program name using RunMode and BuildInfo, distinguishing
between client, core, and monolithic.
Track the last successful upgrade step (upgrade_###_XXX.sql) within
each schema version, storing it within 'coreinfo' table as
'schemaupgradestep'. When a schema upgrade finishes, clear
'schemaupgradestep' and set 'schemaversion'.
This allows for resuming multi-step schema upgrades that were
interrupted in the middle.
Whenever starting a schema upgrade, also check the value of
'schemaupgradestep'. One of two states exist:
1. Empty ('') or nonexistent
No interrupted schema upgrade, start the next schema version
upgrade from the first query.
2. Contains text, e.g. 'upgrade_010_alter_sender_64bit_ids'
The schema upgrade was interrupted, skip schema upgrade steps
including the specified successful step, and resume from the next
step.
For case 2, if the schema upgrade step cannot be found, warn and bail
out. This should only happen if:
1. The storage of successful query glitched, or the database was
manually changed
2. Quassel changed the filenames of upgrade queries, and the local
Quassel core version was replaced during an interrupted schema
upgrade
Modify SqliteStorage and PostgreSqlStorage to fetch/save the
'schemaupgradestep' key. Clearing this key is done atomically within
updateSchemaVersion().
(Ideally, the whole upgrade would be wrapped in a transaction, but
that doesn't seem to be easily possible.)
Modify upgradeQueries() to return a list of query strings and
resource filenames, used for tracking the upgrade step and providing
clearer feedback on what steps fail.
