Before now table definitions could define collations only for MariaDB using the
MariaDB's collation names directly.
Now instead definitions get a slightly more abstract collation name syntax, but
only supporting the collations utf8mb4_bin and utf8mb4_unicode_(cs|ci) (wrapped
as utf8_bin, utf8_general_(cs|ci)), because those are the ones that have
practical use for GNU social.
Which also means that on MariaDB the formerly used utf8mb4_general_(cs|ci) have
been superseded by utf8mb4_unicode_(cs|ci), as they are the more modern
replacement.
Introduce collation support on PostgreSQL which results in use of the C (POSIX)
collation as utf8_bin and the und-x-icu collation as utf8_general_cs.
utf8_general_ci is also mapped to und-x-icu, which makes it case-sensitive,
unfortunately.
Instead of relying on the MariaDB's ON UPDATE CURRENT_TIMESTAMP trigger update
"modified" attributes in Managed_DataObject. Every raw query that needs
adjusting is adjusted, as they won't update "modified" automatically anymore.
The main goal behind this change is to fix "modified" updates on PostgreSQL.
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.
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.
On big databases these queries from the Nodeinfo plugin choked up:
SELECT profile_id FROM notice
WHERE notice.created >= (CURRENT_DATE - INTERVAL '180' DAY)
AND notice.is_local = 1;
SELECT id FROM "user"
WHERE "user".created >= (CURRENT_DATE - INTERVAL '180' DAY);
The code used to operate under the assumption that MariaDB doesn't support
quoting identifiers. Not only is that not exactly true, but MariaDB has
reserved keywords that cannot be used as table or column names unquoted.
use Notice_prefs instead of adding a new field. The rationale here
is simply that the Notice table was _huge_ and I rant into issues
with /tmp filling up when altering the tables. So let's just create
a new table instead.
use Notice_prefs instead of adding a new field. The rationale here
is simply that the Notice table was _huge_ and I rant into issues
with /tmp filling up when altering the tables. So let's just create
a new table instead.
Conversation will now start storing remote URL
The namespace features don't work the way they were written for here
so I fixed that, making the ostatus: namespace properly looked up and
then the homegrown getLink function looks for what is back-compat with
StatusNet etc. if I remember correctly.
