[wp-hackers] Data recovery (post_status?)

[Owen Winkler]

David Chait wrote:
> I'm happy with any solution that is reasonably quick to query, and takes 
> minimal-if-any resources to exclude from queries.  If you have to query a 
> secondary table, or test a character, that'll make it more difficult to 
> 'exclude'.  That's why I proposed post-status==trash, though I admittedly 
> didn't consider the 'how to put things back' for posts vs comments vs ...  I 
> think the period-prefix thing is a potential query bottleneck...
> 
> do we simply need a 'trash' flag on all major object tables?  that just 
> seems overkill in one sense, in another it simplifies stuff greatly.

When did "delete" come to mean "possibly store it somewhere for 
convenient for later retrieval, just in case you didn't really want to 
actually, you know, delete it"?  I never saw any delete buttons labeled 
"Throw this away, but put it somewhere I can get it later if I made a 
mistake".  I can see the advantage of letting users recover from their 
mistakes, but geez.

In any case, using a separate trash table to hold all of this data seems 
silly when the affected tables have a status column that could be set to 
"deleted".  The only thing you lose is the status prior to deletion, 
which would be set to the status with the least impact, for example, 
"draft" or "0"/"moderate".  Everything else would already be set properly.

Deletion dates (if you want to purge deleted things via cron) could be 
stored in postmeta.  For comments, that's a bit trickier.  Are we going 
to add the commentmeta table?  If so, there's the natural place for it. 
  If not, then the purge cron action can simply store (in options) the 
comment ids of all of the comments that it didn't purge during the last 
purge event.  It will only purge comments that are stored in this list.

If you insist on a new column, then make it a NULL-capable date field. 
If the field is NULL, then it's not deleted.  If it is not null, then it 
contains the date the record was deleted.  Every query on those tables 
will then need to check whether that column is NULL to make sure it's 
not returning deleted items.  Since all queries should already be 
checking their status fields directly (post_status = 'publish' will 
automatically ignore rows using the status of 'deleted'), using a flag 
field will be more coding work, data storage, and query overhead for not 
much more gain.

Owen