Reverse similar threads creation order

[squishi]

If you build the similar threads manually from the maintenance page, it always starts with ID number 1.
I would like to reverse the order. It should start with the latest thread and count down.

Should not be impossible. It would require an edit of the vb files, I suppose.
Any ideas?

[Lynne]

The query you are looking for, I think, is in includes/functions_search.php around line 352. You can actually use the hook search_similarthreads_fulltext to add to the query - probably an ORDER BY thread.threadid DESC (I'm not sure, so try it on a test site.)

[squishi]

That sounded good, but the process still started with the first threads.

[Lynne]

Ah.... I thought you meant the query when it is looking for similar threads to put in the table. But, you are looking to do it when you are rebuilding them? Did you know you can start the rebuild in the middle? misc.php?do=updatethread&startat=xxxxx . xxxxx being the threadid to start at. Then it only builds those and the ones greater than that.

If you want to change that query to go backwards, it is in admincp/misc.php, look under do=updatethread and the query that select the threads is right there and it's ordered by threadid and the where statement is threadid >=startat .

[squishi]

I have added a DESC to the sort order of the query you mentioned, but it still started at the first thread. :(

$threads = $db->query_read("
SELECT threadid
FROM " . TABLE_PREFIX . "thread
WHERE threadid >= " . $vbulletin->GPC['startat'] . "
ORDER BY threadid DESC
LIMIT " . $vbulletin->GPC['perpage']
);

[Lynne]

If it is that query (you didn't verify that what you are doing rebuilding the similar threads), then I think you need to get rid of the line about where threadid >= startup. You may have to redo the lines about $finishat since it assumes you are counting up.

Exactly what are you trying to accomplish here? Perhaps there is an easier way to do this.

[squishi]

I think we understand each other correctly now.
I am building the similar threads manually from the maintenance page in the admin backend.
The process starts at thread 3 (which is the first thread on my board).
I'd like it to start at the latest thread and then count down to the first one.
This will allow me to use the similar threads without having the automatic similar thread check enabled (which costs server resources).

[Lynne]

Did you see my suggestion about just adding startat=xxxx to the url to not do the similar threads from the beginning? When you do the rebuild, it automatically does xxxx threads at a time (default is 100). So, if you know that you just want to rebuild the last 10 threads, why not just do startat=(your lastest thread number - 10) ? Your alternative is to rewrite the code to go backwards (redo how $finishat is handled and redo the query), as I said.

[squishi]

For some reason, I cannot run the script in the browser.
I get a 404 error.

[Lynne]

Are you using the correct url? It's a file in the admin cp, so you need to use the correct path to that folder.

[squishi]

I have reversed the order, and told the query to only query thread smaller than startat.
$threads = $db->query_read("
SELECT title, threadid
FROM " . TABLE_PREFIX . "thread
WHERE threadid >= " . $vbulletin->GPC['startat'] . "
ORDER BY threadid
LIMIT " . $vbulletin->GPC['perpage']
);
The process still starts with the first thread.

--------------- Added 1252425524 at 1252425524 ---------------

Hmm, that's weird.
I can load misc.php, but as soon as I add the variables "&do=updatethread&startat=12345", I get a 404 error.

http://mydomain.com/forum/admincp/misc.php&do=updatethread&startat=40000 gives me a 404.
http://mydomain.com/forum/admincp/misc.php loads just fine.

Must be something in the htaccess file, I guess.

--------------- Added 1252425598 at 1252425598 ---------------

There should be a form field added to the maintenance page that lets you define the startat value.

[Lynne]

Your url should be misc.php?do=updatethread&startat=40000

The query you posted is the original query, so I'm not sure what changes you made to it.

[squishi]

Okay. The last link worked. I guess I will do it this way.
Thank you for your support.

--------------- Added 1252438206 at 1252438206 ---------------

Wow, the process is much faster than usual when I start it at 40,000.
It will only consider the posts that are older than id 40,000?
So it will not build the similar threads for older threads?
That's not good.

[Lynne]

Wow, the process is much faster than usual when I start it at 40,000.
It will only consider the posts that are older than id 40,000?
So it will not build the similar threads for older threads?
That's not good.
It only rebuilds the threads that have an id greater than 40000 if you start at 40000.

I seriously don't get what you are trying to do. You either want to rebuild ALL the threads, or do don't. If you are going to rebuild them all, then it doesn't matter if you start at id 1 or you start with the last id - you still have to go through and rebuild them all.

[squishi]

I seriously don't get what you are trying to do. You either want to rebuild ALL the threads, or do don't. If you are going to rebuild them all, then it doesn't matter if you start at id 1 or you start with the last id - you still have to go through and rebuild them all.

I want to rebuild all of the threads.

And it does matter.
On my forum, rebuilding the similar threads takes over 24 hours.
And the process often just dies somewhere at 25,000 threads.
If I start at the end, I can rebuild the similar threads for those latest threads and do not have to worry about the process reaching the oldest threads.

[Lynne]

Well, if you want to start at the end, then like I said, I think you will have to completely recode that section of the page.

Why don't you want to just turn on the option to create the list of similar threads when the thread is created? Do you really get so many threads created a day where that is going to cause problems? It sounds like what you are trying to do (rebuilding the similar threads all the time) is much more server intensive than just having the option on.