Wedge

Therein lies the thing... it only requires said person to have edited 2 posts and already it's slower by a significant margin (since it's one big query and then one query per row minimum, versus one query to just deal with it)

It might not be done very often but if it were done that way I could see it causing big problems with prolific users who did this, like timeouts and white screens and database inconsistencies.

I don't see how the DB would be inconsistent if every single query dealt with member_id_whatever and the member name data var at the same time...
Oh well, anyway :)

That's the point. If you have to do it row by row, you absolutely must be done inside one page load, or schedule it across page loads, but you have to be much, much more careful than the alternative.

If you can do it in a single query, the query runs atomically and doesn't affect anything else, but if you do it row by row, you have to do it row by row and be sure to be finished before actually deleting the member row.

Or we could just store somewhere a list of lost ids along with corresponding member name. If member not found, retrieve name from list...

I think that's creeping into the realms of over-engineering the solution to something. When you have to keep track of whether you actually made your own changes because of the complexity of making changes, it seems like it's a step too far down a murky road.

The simplest solution, technically, would be to handle it as a transaction but they're not supported on MyISAM and that's almost creating another problem in its own right.

You want to know my solution?

No mem name.
Last edited by (account deleted)

Who cares, after all?

In that case, guess I need to make sure the list of member ids who've edited a post is pushed into the posters query and drop the column.

Mind you, it's going to make imported entries very messy >_<

Why?

Because imported entries won't have the id, only a name, so every edited post will be last edited by (deleted) even if the user is very much not deleted.

unless the display name wasn't changed we could pick up the member's id within the import process.(one extra sql query per row in wedge_messages)

Would slow down the import, but shouldn't be a problem at all..

+1!

That assumes the display name hasn't changed though...