As an introduction, the comments module uses a thread column to properly sort threads not only in timestamp order but also based on what parents the thread has. When a comment has no parents (i.e. is a comment on the posting node) it has just the value, e.g. "148". These codes are generated using the int2vancode and vancode2int functions, and the goal is to have them sort in order as a string. Since strings sort differently than numbers, this works out rather ingeniously.
When the comment is about an existing comment, the thread value gets a dot and a second vancode is generated for what is now one level below the comment. So, lets say comment 148 gets a comment, its thread will be "148.00". If a second comment on 148 is added, it would be "148.01", and so on. Now if a comment on 148.01 is added, its thread would be "148.01.00".
I have a posting with a large number of comments (hence the vancode "148" in my example since they start at "00") . To be fair this came from my phpBB forum via the phpbb2drupal module I recently patched to fix how it assigned thread IDs.
I had a comment 148, a comment on 148 "148.00", and a comment on 148.00, which generated a "148.00.00".
The next comment made was on the original posting. What thread should it get? My guess is "149", but the software gives it "52mbrwh" instead.
The code should take the first value from before the first dot (if there are any dots) and then increment that, but instead it takes the whole value, dots and extra levels and so on, and increments it.
Am I missing something?
This thread field is so large, and the number of threads is probably so few for a given topic, that this is never likely to be a problem. My work on the phpbb2drupal vancode generation problem just happened to have me wandering around the database long enough to notice this.
Should I make a patch and submit it?