core: Fix SQLite realname/avatarurl handling
authorShane Synan <digitalcircuit36939@gmail.com>
Fri, 11 May 2018 05:36:21 +0000 (00:36 -0500)
committerManuel Nickschas <sputnick@quassel-irc.org>
Wed, 23 May 2018 22:33:28 +0000 (00:33 +0200)
commit092e6b212637ffbf68800584b7c1f32d1931b602
tree771173827cbed850de49bbf3881be9a5a52a3666
parent20f446a492d8e681156423f0dc3637db78c45bae
core: Fix SQLite realname/avatarurl handling

In insert_message, when selecting a senderid also match on "realname"
and "avatarurl".  This fixes cases where sometimes senderid would
refer to a sender without a realname after a realname was added, etc.

Test case: start up core, client.  Send several messages quickly after
joining.  Shut down core, check SQLite database "sender" table.

Before this fix, once a sender entry is put in, sometimes
permutations of realname/avatarurl would NOT create a new sender
entry, clearly visible in QuasselDroid's display of of the realname.

After this fix, changing realname/avatarurl causes new sender entries
to be added every single time there's a change, as expected, and they
display correctly in QuasselDroid.

PostgreSqlStorage was immune to this, but for once, not due to being
a better database, but due to how the queries are constructed.  For
PostgreSQL, senders were always fetched separately, properly checking
avatarurl and realname.

NOTE: The realname/avatarurl columns can be NULL values.  Due to
this, we need to coalesce them to '' in order to use the same queries
rather than "column = some value" and "column IS NULL".  Both column
and the input parameter need coalesced in case one or the other is
NULL.  As there's minimal functional difference in protocol handling
between '' and NULL, we consider them the same.

(This could be squashed down if preferred, I just wanted to document
 what was needed to fix this and why only SQLite was changed.)
src/core/SQL/SQLite/insert_message.sql
src/core/sqlitestorage.cpp