field_attach_delete() deletes all fields for the specified object from the current and archive field data tables.
field_attach_delete_revision(), presumably, only deletes the specified revision of the specified object. Obviously this deletes from the archive field data tables. Question: What if the revision being deleted is the current revision? Should the function delete from the current field data table as well, replacing it with the second most recent version from the archive field data table? (This would presume that it is possible to identify what the second most recent version is; we should/can not assume the version ids are monotonically increasing.)
I observe that node.module does not worry about this. node_revision_delete_confirm_submit() (*) basically boils down to
<?php
db_query("DELETE FROM {node_revision} WHERE nid = %d AND vid = %d", $node_revision->nid, $node_revision->vid);
?>so it never deletes from the node table. This corresponds to (what I think is) the fact that you cannot delete the current revision of a node.
Do we want to impose this same restriction in Field API? I'd prefer not to but, as stated above, I'm not sure we have a choice with our current data structures.
(*) ... which is a !#$^&!#$%-ing form submit handler, not an API function! Grrrrr.
Comments
Well, node is our only
Well, node is our only current example of 'revisioned entity', and as you point, it shamelessly avoids the issue, so it's difficult to figure out a 'generic' behavior.
For instance, figuring out the 'second most recent version' without relying on vids arithmetics : means timestamps ? then we'd need fieldable entitites to tell us what their 'timestamp key' is ?
I don't even know if the timestamp approach is the only valid one - or if other entity types wouldn't need their own rules...
I think for now it's safer to say that we don't support deleting the current revision of an entity.
Sort of related : Aren't there some contrib modules out there that are able to change the 'current vid' under us ?
Found this in revision_moderation :
function revision_moderation_publish_confirm_submit($form, &$form_state) {$nid = $form_state['values']['node_id'];
$title = $form_state['values']['title'];
$vid = $form_state['values']['revision'];
db_query("UPDATE {node} SET vid = %d, title = '%s' WHERE nid = %d", $vid, $title, $nid);
(...)
}
And suddenly, we don't have the data for the 'current revision' in the right field_data_* table...
Done
I committed the code last night, and field_attach_delete_revision disallows deleting the current revision (i.e.: it does not touch the field current data table).