refactor database schema for blocked instances #229

New issue

Closed

opened 2022-11-09 23:13:23 +00:00 by Johann150 · 2 comments

Johann150 commented

2022-11-09 23:13:23 +00:00

Owner

Whether an instance is blocked is currently stored in meta.blockedHosts. Instead it would be more practical if this information was stored in the instance table, since instance.suspended is also already stored there.

After this is refactored, it would for example be possible to further simplify the code in packages/backend/src/misc/skipped-instances.ts.

Whether an instance is blocked is currently stored in `meta.blockedHosts`. Instead it would be more practical if this information was stored in the `instance` table, since `instance.suspended` is also already stored there. After this is refactored, it would for example be possible to further simplify the code in `packages/backend/src/misc/skipped-instances.ts`.

Johann150 added this to the (deleted) project 2022-11-09 23:13:23 +00:00

Johann150 commented

2022-12-01 07:01:42 +00:00

Author

Owner

I don't think it is a good idea to change this because the current data model allows you to block an instance that has not been fetched yet, which the new data model wouldn't allow you to do.

Johann150 closed this issue

2022-12-01 07:01:42 +00:00

Johann150 removed this from the (deleted) project 2022-12-01 07:01:47 +00:00

toast commented

2022-12-03 12:21:48 +00:00

Owner

Would it potentially be worthwhile to refactor it into an "instance_relationship" table instead?
This would be useful for:

The UI could be useful and reused.
Extended later (e.g for allowlist stuff).
Still allow blocking non-fetched instances.

Would it potentially be worthwhile to refactor it into an "instance_relationship" table instead? This would be useful for: 1. The UI could be useful and reused. 2. Extended later (e.g for allowlist stuff). 3. Still allow blocking non-fetched instances.