Closed (fixed)
Project:
Comment mover
Version:
4.7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
13 Oct 2006 at 00:18 UTC
Updated:
11 Feb 2008 at 17:54 UTC
Jump to comment: Most recent file
Comments
Comment #1
PMunn commentedI just noticed this as well.
Comment #2
PMunn commentedHere's a patch that fixes it.
It was using the same awful thread ID generation code I replaced in the phpbb2drupal module in this issue. I've fixed that.
It was also grabbing the comments in reverse thread ID order. This meant it was processing them newest to oldest, but adding them into the target node newest to oldest. Oopsie.
I tested it with a forum post with one level of comments and one with multiple levels of comments to be sure the graft still worked as desired. It did.
Comment #3
heine commentedThanks a lot.
The patch has a few problems, however. I've tried it on a new node with threaded comments, oldest first. I've created for comments and gave all comments three children. Next, I made sure that all children of two, three and four and three and four themselves became children of two in one long branch. When finally moving the entire branch two to become a child of comment one, threading was completely off.
Here's an overview of the comment table.
Moving all 2+ comments as a straight branch (child->child->child--//-->child under 2) and all children of 1 as a straight branch under 1).
Pruning 2 (36) and grafting on 13 (41)
Comment #4
PMunn commentedI'm having a hard time understanding what went on in your example, but I'll try to replicate it on a testbed myself within the next couple of days and see what happens. I might make more snapshots in between that will help me see the problem and why not, others too. Thanks for bringing this to my attention.
Comment #5
PMunn commentedI'm not seeing a problem. Here's what I did:
Created four threads, and then two comments per thread.
First, I pruned 03 and grafted it to 02.
Then I pruned 04 and grafted it onto 02.
And lastly I grafted 02 onto 01:
The sorts continue to work.
I have updated the patch with a minor fix. The comment vancodes were starting at 01 when they should start at 00. That's it.
Can you explain in finer detail how to reproduce what you've seen.
Comment #6
heine commentedAn updated patch makes sure the '/' is disregarded when ASC sorting.
Comment #7
PMunn commentedI've snipped the first few lines of the patch which made applying it break. I've seen this before. Some method some developers are using to post patches is tacking on a few lines of information at the top of the file, at least that's how it looks when I download it.
Typically I see patches written with a .patch on the end so I tend to use that suffix on the resulting patch file.
Anyway I tested this patch and the sort is working properly with the SQL change on PostgreSQL.
Comment #8
heine commentedThank you.
Patch in #6 is created using CVS, so we know exactly what revision it is against. Your patch program should simply ignore this (weird it doesn't).
I'll test a few more scenarios, then commit.
Comment #9
heine commentedCommitted to 4.7.x-1.x-dev and HEAD. Will backport to 4.6.
Thanks.
Comment #10
Leeteq commentedif 4.6 is not relevant anymore, maybe this issue is fixed?
Comment #11
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.