On Jul 20, 2006, at 11:26 AM, Dries wrote:

My problem with the trashbin patch is the way it works. I'm not convinced that it should transfer deleted records to a dedicated table. Right now, the trashbin patch stores deleted records in a separate table in serialized format.

not exactly. there is no serialization involved. the deleted_data table stores data one row per column for each row of data deleted from the table. kind of expensive for large deletions, i know...

This is a little bit awkward as it has to circumvent the auto increment IDs or the sequence table when re-injecting the data.

correct, although i haven't seen that to be a problem, since we never go backwards. the data slips right back into where it was.

Why don't we add a status-field with two states -- STATUS_ACTIVE and STATUS_DELETED -- to each of the database tables with records that want to take advantage of the trashbin functionality? Then, the trashbin patch might be a lot easier to grok -- and from an architectural point of view, less awkward. It wouldn't be particularly clever but that is OK: it is super-easy so there is no point being clever to begin with. I'd like to see us explore this path instead.

this would be great, but as i've said before we'll need an SQL query engine in core (or at least functionality that can handle all of the ins and outs of filtering out the deleted data automagically, but allowing access to it when necessary, etc.). also, i think we need to consider how contrib modules will interact with this. will we require a status field in all database tables, or maybe have core auto-add one if it's not already present? the current approach while a little awkward is able to work around all of this.

Plus, this has a number of advantages. Most of all, we'd still able to query deleted data. For example, the filter form on the administer content page (?q=admin/content) would allow us to access delete nodes and we'd be able to use advanced query methods like 'show all deleted nodes from user Joe with the taxonomy term 'Apple'. That is, we get to reuse a lot of the existing UIs and modules.

yes, this would be great as well...