Opened 8 years ago
Closed 8 years ago
#39507 closed enhancement (wontfix)
Increase the length of comment_type field in wp_comments table
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 1.5 |
Component: | Comments | Keywords: | |
Focuses: | Cc: |
Description
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
Change History (4)
#2
@
8 years ago
@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)
.
#4
@
8 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
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.
Worth noting that
comment_type
andpost_type
are bothVARCHAR(20)
whiletaxonomy
isVARCHAR(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.