Increase the length of comment_type field in wp_comments table

[slaFFik]

Currently it's VARCHAR(20), which is very low for no reason (as far as I can see).

Please increase its value to something like VARCHAR(100) (same as email/IP) or similar.

It's quite useful to store in this field the combined type of the comment, where this type is generated based on prerequisites and should be obtained regularly with the comment object (not as a separate query to commentmeta table).

The earliest WordPress version which has this value is 1.5, found here: ​https://codex.wordpress.org/index.php?title=Database_Description&oldid=10394

[dd32]

Worth noting that comment_type and post_type are both VARCHAR(20) while taxonomy is VARCHAR(32).

I'm not sure I see benefit in these fields being longer, they're designed as a short unique grouping of objects.

@slaFFik I'd be interested in hearing more about what you're storing in the field - it kind of sounds like it's metadata that really should just be stored as comment meta, I don't think the extra SQL query should be a blocker for that - if performance is an issue I'd be looking at using an object cache to improve it instead.

Related: #37104 for increasing the post_type length.

[slaFFik]

@dd32 
I have different "objects" of data, each object is represented by several post types in different combinations. To distinguish between ordinary (not mine) comments and comments to my objects I use comment_type field.
This comment type is generated based on CPTs, so comments to some objects will have comment type like prefix_abcde_xyz_12312 or prefix_xyz_foo_bar_baz_34231. As you can see, I'm pretty easily can go outside of varchar(20), and mostly I'm around 35 chars.
Then I query those comments based on abcde, xyz, 12312, foo, bar, 34231 - to get comments for my objects based on type that consists of specific CPTs "refs". I have big number of comments, so working with wp_comments table is faster than also query for meta (like type=>prefix_abcde_xyz_12312, which is bigger than wp_comments and values are also not indexed, obviously).

That's my usecase, where I use comment_type to uniquely group comments by objects, this grouping identifier seems just be longer defined a decade ago of varchar(20).

[slaFFik]

@dd32
Is it possible to have this shipped in 5.0?

[dd32]

I don't personally see the provided use case as a good reason to change this.

It sounds like comment meta is probably a better location for the data.

I could see standardizing on 32char being done, but I don't think standizing outweighs the cost of upgrading existing tables here.

I'm going to close this as wontfix, if any other committers feel differently, they're free to reopen it.