Database limit updates (RELEASE/V3 BUG)

[SpeedyD]

As per #395 icons have been added directly to usernames, which in turn got added to log keeping.

This means that in many sections of the database, there's now an approximate 50 character block of code added.. and with some of the older limits in the database, this will cause a lot of errors.

Tables that I assume will require update:

• character_log, column 'log'
• currencies_log, column 'log'
• items_log, columns 'log' and 'data'
• user_character_log, columns 'log' and 'data'
• user_items, column 'data'
• user_update_log, column 'data'

I strongly suggest upping all of these to varchar(1024) or potentially text and that there's a good check if I missed any other table.

Some of these have a really low maximum, like 191.. :/

..why is the max actually 191? It's such an odd number, I would've expected like.. 256, 512 or 1024, byte numbers, not.. 191.

As you're likely well aware, I'd PR this myself but.. I have no idea how to.

[itinerare]

Yeah this is a fair one/good call.

[SpeedyD]

I found this: https://laravel.com/docs/master/migrations#modifying-columns

The warnings regarding 'needing to keep modifiers' make me nervous. I don't think any of these HAVE modifiers, but ugh.

Also, of course, making a migration also means having to research the current number back to the way it was =_=;

[SpeedyD]

Sidenote: I have found out why 191. LARAVEL. It's a default BY LARAVEL. WHY.

[preimpression]

At a risk of adding a ton of work... why not have a separate attribute that doesn't include the icons, to be included in the log calls? I don't see a purpose for having the full display name vs a simplified version clogging up the database.

I do agree that the log columns should allow for more, seeing as that's a big complaint I've heard

[itinerare]

Yeah, both might be a good idea...

[SpeedyD]

Another approach is perhaps to generate the text every single time, rather than saving the html in the log either way?

For most of these, there's a 'log type' and 'sender_id' and whatnot, could we not have the text be generated..?

[itinerare]

Akin to notifications, yeah, but that would be a pretty significant change, and I'm not convinced it'd be worth the headache it entails.

[SpeedyD]

How about increasing the log and data sizes for patchwork solution a la release 3.0.0, Uri's idea for 3.1.0 and we'll think about the headache for later? :o

[itinerare]

Yeah that's probably the most sensible course of action.

[SpeedyD]

So, the plan is..
Extending the limits for v3:
PR #956 is done, it increases the limits to infinite as they are now texts rather than varchar.

@preimpression's plan; edit out the icons for v3.1:
Not sure who picks this up, we'll see eventually. (See: #955 (comment))

Log system overhaul for v4:
A future problem, frankly. It'll happen eventually. Probably.

[itinerare]

Text isn't infinite but it's long enough to be effectively so |D

TBH if overhauling the log system is a thing that's on the horizon, it is probably inefficient to worry about an alternate display setup....

[SpeedyD]

The thing is... is it REALLY on the horizon? It's an idea, but are we actually going to? :S

[itinerare]

TBH I've thought about it in the past... But, more or less the point is that we should worry about one or the other.