Proposal: Implement undo for post deletion
drac
I've been thinking about how best to implement undo for post
deletion. Heilemann and co already have mockups of the functionality..
so they practically twisted arms :) oooh, the pressure.
My current choices are:
1. Add a status field marking deleted posts. (status = 0 is active,
status = 1 is deleted)
Advantages: we can maintain _all_ the information about the post
(was it a deleted draft? a deleted full post?) and it's relatively
easy to toggle (ie: recover) a deleted post. Simply update the status
field and you've got it back.
Disadvantages: We may need to retain the time of deletion as well.
(For deleted post purging at a later date). Now we're talking two
modifications to the post table. Of course we could track deleted
posts via a completely separate link table but now we're talking about
a join instead of a modified WHERE clause (where status = 0) for
queries so I'm not a huge fan.
I dislike database schema changes. They can break stuff. But I still
like this plan best, currently. However; we could ...
2. Keep delete information in an existing table. ie: posttype?
Or we could,
3. Move "deleted" posts to a separate location; ie: another table. I
don't like this idea (it makes deletes/undeletes _very_ expensive in
database terms) but it has been mooted.
4. Somewhat related to (3), we could export the deleted post onto the
filesystem and reimport it on undelete. (Don't like this because we've
introduced an entirely new class of potential failures to our little
undelete mechanism - ie: disk space, permissions. ick).
5. Move posts into a global trashcan (a graveyard for all deleted
stuff) and allow the user to move it out after inspection. This is
closest to the recycle bin model adopted by operating systems ... but
the ramifications of having a global trashcan make my head hurt. Even
if this proves to be the best option, I may not attempt the feat :)
Now; how long do we keep a deleted post?
1) Forever?
2) A configurable amount of time (time calculated in days; days to
retain posts found in user.userinfo - ie: settable on a per-user basis
with a reasonable default pulled in from options)
3) A configurable number of posts? (ie: when you delete your Nth post,
the earliest deleted post gets binned forever)
4) Some other criteria for deciding when to delete?
I currently favour (2).
Thoughts, opinions... even patches welcome :)
Michael Heilemann
Hi folks,
I've been thinking about how best to implement undo for post
deletion. Heilemann and co already have mockups of the functionality..
so they practically twisted arms :) oooh, the pressure.
Ah, so this is how one get others to code features for oneself :D
Matthias Bauer
> 1. Add a status field marking deleted posts. (status = 0 is active,
> status = 1 is deleted)
>
> Advantages: we can maintain _all_ the information about the post
> (was it a deleted draft? a deleted full post?) and it's relatively
> easy to toggle (ie: recover) a deleted post. Simply update the status
> field and you've got it back.
>
> Disadvantages: We may need to retain the time of deletion as well.
> (For deleted post purging at a later date). Now we're talking two
> modifications to the post table. Of course we could track deleted
> posts via a completely separate link table but now we're talking about
> a join instead of a modified WHERE clause (where status = 0) for
> queries so I'm not a huge fan.
Add a 'deleted' TIMESTAMP column that is either NULL (not deleted) or
the time of deletion.
Simple for SELECT ... WHERE deleted IS NOT NULL, and simple to ORDER BY,
also allows us to have an auto-purge (after 7 days or so) "for free".
Other advantages:
- All the info associated with the record is retained.
- Same approach can be used for other data, which makes it easier to
have a global 'Trashcan'.
-Matt