After adding a verb condition there, MariaDB now prefers the
("created", "id", "is_local") and ("profile_id", "verb", "created", "id")
indices for that query, even though they are slow for the job.
So replace them with ("is_local", "created", "id") and
("profile_id", "verb", "created", "id") respectively.
Also fix the naming of the ("profile_id", "created", "id") index.
There are only three possible visible notice verbs: POST, SHARE and DELETE.
What including all verbs does is it makes limiting (FETCH FIRST) unreliable as
the query will fetch invisible stuff (like favourites) and count it in, but
nothing will be displayed.
NoticeStream only allows POST and SHARE, so this effectively removes tombstones
from the profile page like in 78a111b57d
Introduce a new property in CachingNoticeStream for always checking if there
are any new elements in the stream.
It would be extremely hard to blow InboxNoticeStream, so instead the database
hit will still occur, but it is be much faster than starting fresh.
This fixes a regression introduced in 36a55d8436
There was no checking of attributedTo, actors and referent object IDs to make
sure they exist in the same domain. Therefore, one could spoof messages from
people by doing attributedTo: whoever-i-want-to-spoof
The notice.created sort forced the notice_tag by notice join plain to employ
materialisation, which can have a serious performance penalty depending on the
size of the database.
Sort by notice_tag.created instead, which should be exactly the same.
All verbs for not visible notices are filtered out, so this should not
break the timeline.
Additionally, filter by profile outside of the derived relation as that shows
better performance in PostgreSQL and MariaDB both.
It appears this was added to display "tombstones" of deleted notices.
However, it has other side-effects and the concept of keeping them visible has
not been adopted by the wider fediverse.
Avoid the use of deprecated MariaDB "zero dates" globally. If they're present
as attribute defaults somewhere, they will be replaced with NULL implicitly.
The existing "zero dates" in MariaDB storage will be left intact and this
should not present any issues.
The "timestamp" type in table definitions now corresponds to DATETIME in
MariaDB with "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP", which
should be close enough to the original behaviour for compatibility purposes.
It is now the recommended type for "modified" attributes, because of the
update trigger on MariaDB. But there is no such trigger implemented on
PostgreSQL as of this moment.
Make common_sql_weight employ standard SQL functions for the timestamp
difference in seconds.
Also replace UTC_TIMESTAMP in the MariaDB-specific part with CURRENT_TIMESTAMP
as it is the only occurence and GNU social sets UTC as a default timezone.
In a delete_orphan_files.php script simplify the main query considerably.
In clean_profiles.php stop using COUNT as if it is ANY, that is unnecessary
punishment for the database. Instead implement the anti-join with a
left outer join.
In Autocomplete and Activitypub_profile use joins instead of a WHERE OR
anti-pattern for the semi-joins.
In lib/ui/galleryaction.php replace a CROSS JOIN with an INNER JOIN.
In actions/sup.php remove a redundant subquery: WHERE is applied before
grouping either way.
