deletion API summary, question
as i mentioned a short time ago, i've been trying to flesh out a deletion API for drupal. i thought i'd take a few minutes and discuss it's current state, and throw out some unfinished business to get perspective from other developers. in working on the trashbin patch, i discovered that it's helpful to think of deletions as happening in packages. when you delete a node, you don't just delete something from the node table--there are related node tables, then hook_delete calls, then nodeapi delete calls (and possibly other calls initiated from the last two in that list). deletions in drupal proceed from the top down, recursing until all items are deleted. that's what i'm calling a package. my current work is based on that viewpoint. package deletions are started with a call to a helper function (called drupal_delete_package at the moment), all relevant deletion operations are passed into the package via drupal_delete, and then packages are deleted via another helper function (drupal_delete_execute). once a package is compiled, there are two hooks that are called: hook_delete_pre -- this is an opportunity for modules to throw objections to a package deletion. any module calling this hook will have access to the information in the entire deletion package, and can throw two kinds of objections: confirm and abort. hook_delete_execute -- this is an opportunity for modules to perform any last minute operations before the package is deleted. for example, a trashbin module would use this hook to store metadata about the package deletion. workflow is as follows: 1. call drupal_delete_package to start the package 2. call drupal_delete as many times as is necessary to fill the package with deletion data 3. call drupal_delete_package again if you wish to start a new deletion package in the same page call (like for admin/node multi- deletes) 4. call drupal_delete_execute to execute the deletion of all packages 5. hook_delete_pre is called, and modules put in confirm and abort objections 6. if there are any confirm objections, then a confirm screen is generated 7. once confirmed, the packages are resubmitted 8. any packages with abort objections are skipped, and warnings are issued 9. remaining packages are deleted whew! the important remaining question: how are we to perform the actual deletions? do we delete the data from the table, or merely mark it as deleted with the addition of a 'deleted' column to all tables? if we're going to take the latter approach, it's important to note that we can't just have a DELETED flag--we need some way to know which deletions belong to which packages, otherwise it's a real mess :) my suggestion is to record a unique package id in the deleted column for each deleted package. sorry for the long post--this is a big job and a relatively complex feature--there's a lot to say! chad
Chad, Sounds like you're giving this some good thought and what you say here makes sense in my opinion. I do have a fear though, that myself and others will become confused as to what "delete" means. The word has a well understood meaning in drupal today, and to anyone familiar with SQL. I'd like to see that meaning preserved. If we change "delete" to mean "move to trash bin", then how will I describe "take something already in the trash bin and 'really delete' it from the database"? I suggest we use a new term (perhaps "remove", "expunge", or "trash") to describe this thing that could mean "move to trash" or "delete from database" depending on configuration. As a module developer, I like knowing that hook_delete means "delete from database". And if my module needs to perform some task when content is moved to trash, I'd rather have a new hook_trash (or somesuch) be invoked. Likewise for hook_nodeapi: $op == 'delete' or $op == 'trash'. That's my 2 cents, -Dave On Friday 21 July 2006 08:58, Chad Phillips -- Apartment Lines wrote:
as i mentioned a short time ago, i've been trying to flesh out a deletion API for drupal. i thought i'd take a few minutes and discuss it's current state, and throw out some unfinished business to get perspective from other developers.
I think "logical delete" is a generally accepted term for this behavior. Justin On Fri, Jul 21, 2006 at 12:04:45PM -0700, Dave Cohen wrote:
Chad,
Sounds like you're giving this some good thought and what you say here makes sense in my opinion.
I do have a fear though, that myself and others will become confused as to what "delete" means. The word has a well understood meaning in drupal today, and to anyone familiar with SQL. I'd like to see that meaning preserved. If we change "delete" to mean "move to trash bin", then how will I describe "take something already in the trash bin and 'really delete' it from the database"?
I suggest we use a new term (perhaps "remove", "expunge", or "trash") to describe this thing that could mean "move to trash" or "delete from database" depending on configuration. As a module developer, I like knowing that hook_delete means "delete from database". And if my module needs to perform some task when content is moved to trash, I'd rather have a new hook_trash (or somesuch) be invoked. Likewise for hook_nodeapi: $op == 'delete' or $op == 'trash'.
That's my 2 cents,
-Dave
On Friday 21 July 2006 08:58, Chad Phillips -- Apartment Lines wrote:
as i mentioned a short time ago, i've been trying to flesh out a deletion API for drupal. i thought i'd take a few minutes and discuss it's current state, and throw out some unfinished business to get perspective from other developers.
On 7/21/06, Dave Cohen <drupal@dave-cohen.com> wrote:
I suggest we use a new term (perhaps "remove", "expunge", or "trash") to describe this thing that could mean "move to trash" or "delete from database" depending on configuration. As a module developer, I like knowing that hook_delete means "delete from database". And if my module needs to perform some task when content is moved to trash, I'd rather have a new hook_trash (or somesuch) be invoked. Likewise for hook_nodeapi: $op == 'delete' or $op == 'trash'.
I think that's a good point to make. Modules that maintain their own files (in my case, the audio module) are going to need to make accomodations for the wastebin/trash concept. andrew
On Friday 21 July 2006 10:58, Chad Phillips -- Apartment Lines wrote:
in working on the trashbin patch, i discovered that it's helpful to think of deletions as happening in packages. when you delete a node, you don't just delete something from the node table--there are related node tables, then hook_delete calls, then nodeapi delete calls (and possibly other calls initiated from the last two in that list). deletions in drupal proceed from the top down, recursing until all items are deleted. that's what i'm calling a package.
my current work is based on that viewpoint. package deletions are started with a call to a helper function (called drupal_delete_package at the moment), all relevant deletion operations are passed into the package via drupal_delete, and then packages are deleted via another helper function (drupal_delete_execute).
once a package is compiled, there are two hooks that are called:
hook_delete_pre -- this is an opportunity for modules to throw objections to a package deletion. any module calling this hook will have access to the information in the entire deletion package, and can throw two kinds of objections: confirm and abort.
hook_delete_execute -- this is an opportunity for modules to perform any last minute operations before the package is deleted. for example, a trashbin module would use this hook to store metadata about the package deletion.
workflow is as follows:
*snip* In OO circles, this is known as the Command Pattern, and is effectively THE way to handle "undo" operations. In an OO system, you don't do an action. You instantiate a command object for said action with the data it needs, then call ->execute() on it and push it onto a stack. To undo, you simply pop off the stack and call ->undo(). The object itself still "knows" how to undo itself. What you're calling a package sounds to me like a command object. The single command "Delete node 123" has a whole bunch of things inside it that have to be done (delete/trash from various tables, run hooks, delete/move files on disk, etc.) Now I am NOT bringing back the "we should use OO classes and objects" debate, nosir. :-) I'm just wondering if there's some way we could leverage that conceptual encapsulation here. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
participants (5)
-
andrew morton -
Chad Phillips -- Apartment Lines -
Dave Cohen -
Justin -
Larry Garfield