[development] Have you ever laughed fate in the face?

[Chad Phillips -- Apartment Lines]

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...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060720/7899c5f1/attachment.htm