Add option to be notified when a followed user posts

[Gargron]

Equivalent of YouTube's "bell" button.

Fix #4890

To support changing only notify or only show_reblogs settings for follows, without requiring the client to remember and send along the other value every time, I've changed how defaults for those values are set. The import from CSV service was relying on old defaults behaviour because a CSV import where columns are omitted means we want to reset the omitted values back to defaults, so I had to change that service.

[mstdn]

This would be a amazing feature

[brawaru]

@Gargron any chance to revive this after 3.2.0 is released?

[ClearlyClaire]

Now, the schema.rb file is somehow missing the new columns…

[Gargron]

Hi @takayamaki, I have a question. I am creating a new index on notifications (account_id, type) for this PR. Would it make sense to add the order clause to it and would that make the (account_id, id) index redundant? When I try to EXPLAIN a typical notifications query, it seems to (currently, before this PR) use the account_activity index (account_id, activity_id, activity_type), I'm not sure when (account_id, id) is used?

[takayamaki]

Would it make sense to add the order clause to it?

When no order specified, sorting are not cause. The records will probably be implicitly sorted by ID.

When specified created_at, it may cause sort. However it may same as liner scan(created_at may are same as id usually).

Other cases, insert order condition column after account_id.

would that make the (account_id, id) index redundant?

May be yes.
All indexes have primary key as last column implicitly.
In this case, primary key is id.
So, difference is that id are asc or desc.
How effect this difference to performance, I seem little.

When I try to EXPLAIN a typical notifications query, it seems to (currently, before this PR) use the account_activity index (account_id, activity_id, activity_type), I'm not sure when (account_id, id) is used?

fmm…
index (account_id, activity_id, activity_type) covers (account_id, id). The former will usually be used.

It may be used when the index becomes very very very large and the postgres planner wants to reduce the reading of the index.