This commit introduces support for AccountMigration federation message
receive. It covers the cases when the new home pod for a user is remote
respective to the recepient pod of the message. It also allows to initiate
migration locally by a podmin from the rails console. This will give the
pods a possibility to understand the account migration event on the
federation level and thus future version which will implement migration
will be backward compatible with the pods starting from this commit.
we released that in 0.5.0.0 in 2015, we do not support skipping majors
anyway, and this is broken in Rails 5, so let's remove this. If people
upgrade from before 0.5.0.0, they have to upgrade via 0.6.0.0, but
that's written in the documenation.
... this breaks the Rails 5 upgrade, and it's actually no longer needed.
New installations will have the right size anyway, and even if some
older installations miss the migration by not updating for 2 years, it
still doesn't matter since there is no risk that we will ever have
emojis in our migration filenames.
Before #6873 we deleted contacts when someone blocks a person, but we
didn't drop the notification for the started sharing event. In #6864
we try to get the contact for the notification, which is not there
anymore.
So we need to remove the notifications for the contacts that don't exit
anymore.
This migrations runs only if the old 20150404193023_participation_counter
migration has not been run.
The new migration is a lot faster, because it runs after the
participation-cleanup migration has been run, so the participation table
is now a lot smaller for people upgrading from 0.5.x to 0.6.x.
It also doesn't remove manually created participations (without likes,
comments or poll participations on the same post).
Fixes#6786
* remove author_signature column
* delete all self-participating participations
* delete all participations where author and post-author are remote
* delete all duplicate participations
* delete all participations without post
* create unique index
Following query takes over 20 minutes and fills up the database:
SELECT * FROM participations WHERE author_id = XXXXX
On servers with a huge participations-table this is a serious
performance issue which is easily fixed by the author_id index
Signed-off-by: Lukas Matt <lukas@zauberstuhl.de>
We can determine diaspora_handle from a relation with people for the
shareables (posts, photos). So we don't need to store diaspora_handle in
the DB. Also remove tmp_old_id from photos which is not refenrenced anywhere.
