12345678910111213141516171819 |
- ---
- title: RFC: Restructuring the database
- author: notabug.org/someonewithpc
- time: Tue, 30 Jun 2020 18:21:32 UTC
- status: open
- ---
- author: notabug.org
- time: Tue, 30 Jun 2020 18:21:32 UTC
- content: -----
- I'd like comments on the commits ~~[20b0c4a3a6](https://notabug.org/diogo/gnu-social/commit/20b0c4a3a6b38b3631fdd00fd967ff973dde0e77)~~ [a17072af62](https://notabug.org/diogo/gnu-social/commit/a17072af6291d8f56b7f37901caf39d3b048033e) and [a56d64678b](https://notabug.org/diogo/gnu-social/commit/a56d64678b22158cd04ecf35200a975838f1a7a5), on branch v3
- -----
- author: notabug.org
- time: Tue, 30 Jun 2020 21:55:38 UTC
- content: -----
- # What A summary of the changes: 1. Renamed `notice` to `activity` 1. Deleted `activity.url` 1. Deleted `avatar.filename` 1. Removed all OAuth1 related tables (`consumer`, `nonce`, `oauth_application{,user}`, `oauth_token`, `token`) 1. Removed `file.filename`, added `file.is_local`, renamed `date` to `timestamp` 1. Removed `file_redirection` 1. Removed `file_thumbnail.{filename,url,url_hash}` 1. Renamed `subscription` to `follow` 1. Renamed `user_group` to `group`, added `profile_id` as unique key 1. Removed `local_group` 1. Renamed `location_namespace` to `location_service` 1. Removed `login_token`, `remember_me` and `session` 1. Renamed `attention` to `notification` 1. Removed `old_school_preferences` 1. Removed `reply` 1. Renamed `unavailable_status_network` to `reserved_nickname` 1. Removed `schema_version` 1. Removed notification settings from `user` table 1. Replaced `user_im_prefs` with `user_notification_prefs` 1. Removed `user_username` 1. Changed `modified` fields to use `timestamp`s # Why 1. The `notice` table had all sorts of activity streams objects 1. Activities can have more than one url, and this relation is made with the `file` table already, so this field is not necessary 1. avatar files can be identified by `'id-height_width'` 1. We'll use [AuthBucket's OAuth2](https://github.com/authbucket/oauth2-symfony-bundle) 1. Filename will be replaced with it's hash, the title will have it's description. `is_local` used to distinguish local attachments from remote attachments or urls. `date` was an unix timestamp, from the HTTP query 1. Superfluous table, final url stored in `file`, `redirection_count` irrelevant 1. As with `file`, file thumbnails can be identified by `'hash-height_width'`. `url{,_hash}` is already in the `file` table 1. Subscription makes it sound like a paid comercial product, follow is a more common term for social networks 1. `user_group` suggests a join table between `user` and `group`. A previous bug prevented the used of `profile_id` as an unique key, but it's no longer relevant and a `profile` can be in a `group` at most once 1. This table was always used in a join with `group`. `group` already has `is_local` 1. Namespace was a confusing term, but it turns out it was just meant to identify a service an id belongs to, in case another location service is used in the future 1. Login and session will be handled with Symfony's implementation. Session will have [a new table](https://symfony.com/doc/current/session/database.html#store-sessions-in-a-relational-database-mysql-postgresql), to be implemented when I get there 1. Just a more standard name 1. These settings are deprecated, `conversation_tree` is a plugin 1. Old table, `activity` already has a `reply_to` field (which is indexed) 1. Very bad name 1. Handled by Doctrine 1. Combinatorial explosion of needed fields 1. See above. This table can have all discrete settings for each type of transport (email, xmpp, sms, etc) 1. Old table, not used in core. Seemingly used only for the LDAP plugin, which will be implemented in terms of [Symfony's implementation](https://symfony.com/doc/current/security/ldap.html) 1. For consistency, we'll have the ORM handle it with [this](https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/timestampable.md). # Aditional Questions - Should we keep SMS support? I'm not sure if it's currently functional and if it's worth making it so - What to do about repeats of deleted activities? I think we should recurse on the `repeat_of` field and display the content we find there, not make a copy. This way deleting something will actually delete it (on this instance)
- -----
|