On PostgreSQL:
- Parse defaults for strings and booleans properly.
- Parse the "serial" definition type properly.
- Get information on the "enum" definition type.
- Re-work getting information about keys/indices.
On MariaDB:
- Get information about lengths in indices.
- Get foreign key information separately from the rest as they can have
colliding names.
This adds a requirement for all definitions that have foreign keys to also
require indices for all source (local) attributes mentioned in foreign keys.
MariaDB/MySQL creates indices for source attributes automatically, so this
serves as a way to get rid of those automatic indices and create clean explicit
ones instead.
In PostgreSQL, most of the time, indices on the source are necessary to
decrease performance penalty of foreign keys (like in MariaDB), but they aren't
created automatically, so this serves to remove that difference between
PostgreSQL and MariaDB.
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.
This way UNKNOWN (NULL) explicitly turns to FALSE when three-valued logic is
reduced to binary.
In pgsqlschema, however, use "IS FALSE" as boolean attributes in pg_index are
non-nullable, there is no outer join and there's no clear preference for NULL
reduction.
Over-complicated constructions in TagCloud queries have been simplified, which
should not affect their performance.
Additionally, in TagCloud's lib/subscriptionspeopleselftagcloudsection.php
a typing mistake in an equi-join of "profile_tag" and "profile_list" on
"tagger" was fixed.
That regression was introduced in f446db8e2a
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
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.
The Census event is now replaced with module settings for populating the
protocols array. With this we can shutdown some plugins and still make
them be checked by TFN.
The performance:high config is now added when deciding whether or not to
do online lookup after the offline lookup fails.
default:
- Add default values for the TFN protocol setting
EVENTS:
- Remove Cencus event
TheFreeNetworkModule
- Remove Census event handler, update protocols array to use module's settings
- Use performance:high config when deciding to do online lookup
install.php:
installer.php:
- add option field and handle logic
display.css:
- hardcode ssl's label margin-top value so all options are correctly displayed
This was to keep the following two commits readable
- actions/showstream.php
- actions/userbyid.php
- lib/modules/ActivityHandlerModule.php
- lib/modules/ActivityHandlerPlugin.php
- lib/notices/conversationnoticestream.php
- lib/notices/noticelistitem.php
- lib/notices/noticestream.php
- lib/notices/threadednoticelistitem.php
This should fix nulls on explorer lookups inputed by postman after generate_followers/getSubscribers, that I think were caused by calling common_profile_uri that, curiously, only handles local profiles
Use $object->sqlValue('NULL') (identical to DataObject_Cast'ing) instead and
fix related issues like (email|sms)settings considering these NULLs as a
false positive for the E-Mail address still being set when it's been removed.
There could also be security implications to the now-disabled approach of
considering 'NULL' strings as SQL NULLs.
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.
Issue description as reported by aab:
2019-08-28 17:34:48 LOG_ERR: [khp.ignorelist.com:61055.f5f7f51c GET /api/statuses/show/178372.atom] ServerErrorAction: 500 Class 'OAuthRequest' not found
2019-08-28 17:39:50 LOG_ERR: [khp.ignorelist.com:65390.4483ff85 GET /api/statusnet/conversation/104672.rss] Handled serverError (500) but cannot output into desired format ('rss'): 'Class \'OAuthRequest\' not found'
2019-08-28 17:39:50 LOG_ERR: [khp.ignorelist.com:65390.4483ff85 GET /api/statusnet/conversation/104672.rss] ServerErrorAction: 500 Class 'OAuthRequest' not found
2019-08-28 17:40:49 LOG_ERR: [khp.ignorelist.com:65390.4c745f68 GET /api/statuses/show/18132.atom] Handled serverError (500) but cannot output into desired format ('atom'): 'Class \'OAuthRequest\' not found'
2019-08-28 17:40:49 LOG_ERR: [khp.ignorelist.com:65390.4c745f68 GET /api/statuses/show/18132.atom] ServerErrorAction: 500 Class 'OAuthRequest' not found
2019-08-28 17:47:41 LOG_ERR: [khp.ignorelist.com:65390.42ee9fd4 GET /api/statusnet/conversation/133023.as] Handled serverError (500) but cannot output into desired format ('as'): 'Class \'OAuthRequest\' not found'
lib/default.php
- Add RemoteFollow to the list of default plugins
RemoteFollowPlugin:
- Subscribe events to add the remote-follow button
RemoteFollowInitAction:
- Handles the remote-follow form and getting the redirection url for follow completion
RemoteFollowSubAction:
- Handles the remote profile pulling and actual following
For reference (raised by rozzin in IRC):
* http://foldoc.org/module
* http://foldoc.org/library
* http://foldoc.org/plugin
As noted by XRevan86, modules are not necessarily non-essential.
As we will keep the modules directory in GS root [therefore, near to
plugins/], it is evidenced the difference between both.
This is a simple yet fundamental structural change. It doesn't change
functionality but makes clearer the way we understand GNU social's
internals.
This commit does the necessary rework to store private messages
as Notices and to support Federation. The plugin's README presents
some more detail about the changes and future work that is still
required to do.
This solves the problem of routes that differ only in having
or not $_GET params. The ones not having params (static) were
being matched first during URL generation.
The way this problem was solved was by separating the $reverse
array in both $reverse_statics and $reverse_dynamics and explicitly
traversing this last one first in the generation function. Note that
maintaining the $reverse array and unshifting dynamic routes to its
head ( and therefore to the front of the static ones ) doesn't work
since even among dynamic routes the order of arrival should be kept.
