[wp-hackers] Data recovery (post_status?)
ringmaster at midnightcircus.com
Sun Feb 12 16:11:09 GMT 2006
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.
More information about the wp-hackers