#163 RFC: Restructuring the database

Open
opened 3 years ago by someonewithpc · 1 comments

I'd like comments on the commits 20b0c4a3a6 a17072af62 and a56d64678b, on branch v3

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
someonewithpc commented 3 years ago
Collaborator

What

A summary of the changes:

  1. Renamed notice to activity
  2. Deleted activity.url
  3. Deleted avatar.filename
  4. Removed all OAuth1 related tables (consumer, nonce, oauth_application{,user}, oauth_token, token)
  5. Removed file.filename, added file.is_local, renamed date to timestamp
  6. Removed file_redirection
  7. Removed file_thumbnail.{filename,url,url_hash}
  8. Renamed subscription to follow
  9. Renamed user_group to group, added profile_id as unique key
  10. Removed local_group
  11. Renamed location_namespace to location_service
  12. Removed login_token, remember_me and session
  13. Renamed attention to notification
  14. Removed old_school_preferences
  15. Removed reply
  16. Renamed unavailable_status_network to reserved_nickname
  17. Removed schema_version
  18. Removed notification settings from user table
  19. Replaced user_im_prefs with user_notification_prefs
  20. Removed user_username
  21. Changed modified fields to use timestamps

Why

  1. The notice table had all sorts of activity streams objects
  2. Activities can have more than one url, and this relation is made with the file table already, so this field is not necessary
  3. avatar files can be identified by 'id-height_width'
  4. We'll use AuthBucket's OAuth2
  5. 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
  6. Superfluous table, final url stored in file, redirection_count irrelevant
  7. As with file, file thumbnails can be identified by 'hash-height_width'. url{,_hash} is already in the file table
  8. Subscription makes it sound like a paid comercial product, follow is a more common term for social networks
  9. 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
  10. This table was always used in a join with group. group already has is_local
  11. 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
  12. Login and session will be handled with Symfony's implementation. Session will have a new table, to be implemented when I get there
  13. Just a more standard name
  14. These settings are deprecated, conversation_tree is a plugin
  15. Old table, activity already has a reply_to field (which is indexed)
  16. Very bad name
  17. Handled by Doctrine
  18. Combinatorial explosion of needed fields
  19. See above. This table can have all discrete settings for each type of transport (email, xmpp, sms, etc)
  20. Old table, not used in core. Seemingly used only for the LDAP plugin, which will be implemented in terms of Symfony's implementation
  21. For consistency, we'll have the ORM handle it with this.

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)
# 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)
Sign in to join this conversation.
No Milestone
No assignee
1 Participants
Loading...
Cancel
Save
There is no content yet.