Database naming changes

[tobyzerner]

As per https://gist.github.com/tobyzerner/b189580dd17b9def574f92692faa0e56

---

Edit by @luceos

• update phpdoc
• update existing properties in flarum/core where a renameColumn was executed Database changes #1344
• update properties in core extensions where a renameColumn was executed
• modify the accessor in User for the avatar_url c31c1ea
• migrations for core; Database changes #1344
• migrations for suspend ext
• migrations for tags ext
• add indices see comment by Toby
• solve preferences drop from users, table or column
  • user notifications table
  • all other preferences to columns on users

[franzliedke]

One more change: see c31c1ea.

[luceos]

@tobscure the api-keys will have an allowed_ips column, but you didn't mention it being nullable. I can safely assume it should be nullable right?

[tobyzerner]

yes :)

[luceos]

@flarum/core I suggested to @tobscure to change columns related to users to be postfixed with _by. A good example of this is:

Old: hide_user_id, new hidden_user_id, suggestion hidden_by.

Another question is why are we migrating columns to types that aren't supported by Laravel natively. This will limit our ability to support other drivers than MySQL in the future (even though Laravel supports several others). This is related to the settings table value column migrating to LONGBLOB which can only be done using a raw ALTER query.

Let me know what you think!

[luceos]

@tobscure can you explain to me what needs to be done with this:

[franzliedke]

@luceos The _by postfix sounds sensible, is there any apparent convention in Toby's initial plan? If not, then go with it, I'd say.

As far as non-supported column types are concerned: if possible, we should avoid that, you are right. Can you list the columns (and their types) that use those strange types? (Or is that value column the only one?) Then we can decide on a case-by-case basis whether the benefits that those types give us may be worthy to keep.

[tobyzerner]

I believe I didn't initially propose a _by suffix because I was trying to consolidate conventions, and the user relationship is already covered by the foreign key convention:

• Foreign key -> {verbed}_{entity}_id (eg. hidden_user_id)
  • Verb can be omitted for primary relationship (eg. post author is just user_id)

_by on the other hand would be creating a special case for the users table, and makes the relationship with the users table non-explicit (it's not necessarily clear in the column name that the value of the column should be a user ID).

I'm not necessarily against this if you guys think it's better, just explaining the original reasoning.

---

The posts_users table is literally just those two columns. Other extensions (eg. likes) can add columns in the future.

Stick with blob for settings value then :)

[franzliedke]

Very good reasoning, Toby. That "no special case for user IDs" part convinced me. 😉

[luceos]

Okay so:

• don't do the _by
• but do stick to existing laravel migrations builder methods
• stick to blob for settings.value
• posts_users comment related to extensibility can be ignored

Got it.

[luceos]

Waiting for #1339 to be merged so the foreign key can work again.