This commit fixes a bug where only TAGMSGs with a `+react` tag would be
stored, when a `+draft/react` tag is normative. I have kept messages
containing `+react` as well, as they will most likely be used in the
future.
I have also reversed the order of tag inspection, as I found the new
order to be more readable.
This commit makes the source and destination network distinction
explicit. This is necessary, as the source and destination network may
not have the same ID in the database, and thus associations will be broken
when migrated.
This commit takes insert query compilation and transaction creation out
of the critical loop for migrating message logs. I have tested with
the sqlite backend, and a speedup of approximately 40x has been achieved
for log migration.
Currently, if times sent to `CHATHISTORY TARGETS` are reversed (e.g.
current time occurs first, and initial time occurs second) then no
targets will be returned from the database backend.
Changes have been tested with the sqlite backend.
We may asynchronously receive an upstream's connection status after
the network has been removed.
Sending an update is pretty bad since it's interpreted by clients
as a new network.
This passes the STATUSMSG isupport through, and it ignores statusmsg prefix when routing messages through the PRIVMSG, NOTICE, and TAGMSG handler so they will show up in the correct history. Because it doesn't modify the message the statusmsg sigils show up correctly for the user on receipt.
Without this PR the statusmsg messages still come through to the client, but they get misrouted by clients expecting STATUSMSG to be specified in 005 and they don't go into the right channel history.
Closes: https://todo.sr.ht/~emersion/soju/124
Previously, we would pass SQLite FTS5 MATCH queries as is from the
SEARCH parameter, when searching for messages.
By default FTS5 queries follow a specific syntax, e.g. AND, OR, ...
can be used to filter searches logically.
Passing special characters in these unescaped queries, like `.`,
would be rejected by SQLite, failing the SEARCH request.
Here, in order to replicate PostgreSQL and FS behavior, we simply
want to search for the string as is, and not give it glob or logic
operators semantics.
To do that, we quote each token of the string, skipping over
separators.
