Actually, that won't be a problem either.
When a message is deleted on SI, it physically removes it from the table then renumbers all of the ordinals after it (a process that takes FOREVER, though the query and indexes looks exactly correct to me).
On iHub, each message has a bit that's toggled (True=message will display; False=it won't). A far faster way to "delete" messages, plus it makes undeleting them a lot easier. Important on a site where users can do the deleting.
It is, however, a bit of a PITA when displaying, listing, or searching messages. The system has to make sure the message isn't a deleted one and act accordingly if it is. Okay, it's a BIG PITA. And not only is there a bit determining whether a message is displayed or not, there's another that determines whether or not it can be deleted. So that if Matt restores a message, nobody else can delete it.
Overall, I prefer iHub's method, but it might not be the most efficient since it imposes some overhead in searching, listing, and displaying that just don't exist on SI. And since deleting is a comparatively rare event, it's probably worthwhile to make the overhead heavier on deletes for the sake of more efficient searching, listing, and displaying.
I'll have to give it some thought.
FWIW, the delete/renumber thing dates back to Brad. But when he did it, it was fast. It was so fast that I was able to write a quick PERL script when Spamo Profundo and company invaded the site; a script that stepped through each of their hundreds of messages and deleted them. Back then, a delete only took a few seconds, most of which was just the time it took for the page to re-display over my dialup connection.
It slowed down when Go2Net converted the system to Oracle. I've spent a lot of time looking at that process and can't really see why it's so slow. But it is! If I delete just one message, it takes 30-60 seconds for the delete to finish happening. And the whole site slows to a crawl until the delete is finished.
I guess the important thing is that you are displaying the absolute message number in the resolved URL.
Yeah, though conventional wisdom says to always use server.transfer instead of response.redirect, I almost always use the latter because the former can leave you with a bogus URL.
if someone right clicks on Previous/Next and copy/pastes that shortcut
Very unlikely to happen, and if someone does that, they deserve the results they'll get if the thread gets renumbered. |
