Voting starts in March for the Drupal Association Board election.
Note: This is issue is part ofand is only meant for planning and governance sign-offs. Work will happen in child issues of this plan.
Some historic background: http://drupal4hu.com/node/233
This phase will deprecate the traditional delete method in our entity storage API and introduce two new methods; archive and purge. This is primarily important for replication and conflict management (see phase H) but also enables things like Trash module (see phase E).
The archive method is the logical replacement of the traditional delete method. But instead of erasing the entity from the database archiving will save a new revision with a boolean base field called "deleted" or "archived" set to TRUE. The storage API will add conditions on this base field where necessary. This method will also invoke a new hook called
The purge method will erase an entity from the database and invoke
hook_entity_purge(). The purge method will also invoke the deprecated
hook_entity_delete() for backward compatibility reason as the traditional behaviour of this hook is to erase things from the database.
The advantage with deprecating the delete method is that we can introduce this in a backward compatible way. The archive and purge methods also have more explicit names to what they actually do, while delete is more ambiguous.
A product manager needs to sign-off on this plan as the above phases are required as part of a planned initiative.
A framework manager needs to sign-off on this plan as the above phases introduces major API additions (archive and purge).
The sub-system maintainers for the Entity API needs to sign-off on this plan as it significantly impacts the Entity API.
- Product manager - pending
- Framework manager - pending
- Sub-system maintainers - pending