Commit b028d317 authored by webchick's avatar webchick

Revert "git commit -m Issue"

This reverts commit a234a4fa.

Bad commit message. :P
parent a234a4fa
......@@ -112,6 +112,9 @@ function hook_field_extra_fields_alter(&$info) {
* appears in edit forms, while @link field_formatter formatters @endlink
* specify how the field appears in displayed entities.
*
* A third kind of pluggable handler, storage backends, is defined by the
* @link field_storage Field Storage API @endlink.
*
* See @link field Field API @endlink for information about the other parts of
* the Field API.
*/
......@@ -538,10 +541,11 @@ function hook_field_update_forbid($field, $prior_field) {
/**
* Acts when a field record is being purged.
*
* In field_purge_field(), after the field definition has been removed from the
* the system, the entity storage has purged stored field data, and the field
* info cache has been cleared, this hook is invoked on all modules to allow
* them to respond to the field being purged.
* In field_purge_field(), after the field configuration has been removed from
* the database, the field storage module has had a chance to run its
* hook_field_storage_purge_field(), and the field info cache has been cleared,
* this hook is invoked on all modules to allow them to respond to the field
* being purged.
*
* @param $field
* The field being purged.
......@@ -555,10 +559,11 @@ function hook_field_purge_field($field) {
/**
* Acts when a field instance is being purged.
*
* In field_purge_instance(), after the instance definition has been removed
* from the the system, the entity storage has purged stored field data, and the
* field info cache has been cleared, this hook is invoked on all modules to
* allow them to respond to the field instance being purged.
* In field_purge_instance(), after the field instance has been removed from the
* database, the field storage module has had a chance to run its
* hook_field_storage_purge_instance(), and the field info cache has been
* cleared, this hook is invoked on all modules to allow them to respond to the
* field instance being purged.
*
* @param $instance
* The instance being purged.
......
......@@ -48,7 +48,22 @@
* allows any module to act on Field Attach operations for any entity after the
* operation is complete, and access or modify all the field, form, or display
* data for that entity and operation. For example, field_attach_view() invokes
* hook_field_attach_view_alter().
* hook_field_attach_view_alter(). These all-module hooks are distinct from
* those of the Field Types API, such as hook_field_load(), that are only
* invoked for the module that defines a specific field type.
*
* field_attach_load(), field_attach_insert(), and field_attach_update() also
* define pre-operation hooks, e.g. hook_field_attach_pre_load(). These hooks
* run before the corresponding Field Storage API and Field Type API operations.
* They allow modules to define additional storage locations (e.g.
* denormalizing, mirroring) for field data on a per-field basis. They also
* allow modules to take over field storage completely by instructing other
* implementations of the same hook and the Field Storage API itself not to
* operate on specified fields.
*
* The pre-operation hooks do not make the Field Storage API irrelevant. The
* Field Storage API is essentially the "fallback mechanism" for any fields that
* aren't being intercepted explicitly by pre-operation hooks.
*
* @link field_language Field language API @endlink provides information about
* the structure of field objects.
......
......@@ -69,6 +69,10 @@
* fields, instances, widgets, and related information defined by or with the
* Field API.
*
* - @link field_storage Field Storage API @endlink: Provides a pluggable back
* -end storage system for actual field data. The default implementation,
* field_sql_storage.module, stores field data in the local SQL database.
*
* - @link field_purge Field API bulk data deletion @endlink: Cleans up after
* bulk deletion operations such as deletion of field or field_instance.
*
......@@ -109,11 +113,15 @@
/**
* Load the most recent version of an entity's field data.
*
* @see field_attach_load().
*/
const FIELD_LOAD_CURRENT = 'FIELD_LOAD_CURRENT';
/**
* Load the version of an entity's field data specified in the entity.
*
* @see field_attach_load().
*/
const FIELD_LOAD_REVISION = 'FIELD_LOAD_REVISION';
......@@ -151,7 +159,10 @@ function field_help($path, $arg) {
'#theme' => 'item_list',
'#items' => $items['items'],
);
$output .= drupal_render($item_list);
$output .= drupal_render($item_list) . '</dd>';
$output .= '<dt>' . t('Managing field data storage') . '</dt>';
$output .= '<dd>' . t('Developers of field modules can either use the default <a href="@sql-store">Field SQL Storage module</a> to store data for their fields, or a contributed or custom module developed using the <a href="@storage-api">field storage API</a>.', array('@storage-api' => 'http://api.drupal.org/api/group/field_storage/8', '@sql-store' => url('admin/help/field_sql_storage'))) . '</dd>';
$output .= '</dl>';
return $output;
}
}
......
......@@ -2,7 +2,7 @@
/**
* @file
* Provides support for field data purge after mass deletion.
* Field CRUD API, handling field and field instance creation and deletion.
*/
use Drupal\field\Entity\Field;
......@@ -17,21 +17,26 @@
* entities as well as deleting entire fields or field instances in a single
* operation.
*
* When a single entity is deleted, the Entity storage controller performs the
* following operations:
* - Invoking the FieldInterface delete() method for each field on the
* entity. A file field type might use this method to delete uploaded files
* from the filesystem.
* - Removing the data from storage.
* - Invoking the global hook_entity_delete() for all modules that implement it.
* Each hook implementation receives the entity being deleted and can operate
* on whichever subset of the entity's bundle's fields it chooses to.
* Deleting field data items for an entity with field_attach_delete() involves
* three separate operations:
* - Invoking the Field Type API hook_field_delete() for each field on the
* entity. The hook for each field type receives the entity and the specific
* field being deleted. A file field module might use this hook to delete
* uploaded files from the filesystem.
* - Invoking the Field Storage API hook_field_storage_delete() to remove data
* from the primary field storage. The hook implementation receives the entity
* being deleted and deletes data for all of the entity's bundle's fields.
* - Invoking the global Field Attach API hook_field_attach_delete() for all
* modules that implement it. Each hook implementation receives the entity
* being deleted and can operate on whichever subset of the entity's bundle's
* fields it chooses to.
*
* Similar operations are performed on deletion of a single entity revision.
* These hooks are invoked immediately when field_attach_delete() is called.
* Similar operations are performed for field_attach_delete_revision().
*
* When a field, bundle, or field instance is deleted, it is not practical to
* perform those operations immediately on every affected entity in a single
* page request; there could be thousands or millions of them. Instead, the
* invoke these hooks immediately on every affected entity in a single page
* request; there could be thousands or millions of them. Instead, the
* appropriate field data items, instances, and/or fields are marked as deleted
* so that subsequent load or query operations will not return them. Later, a
* separate process cleans up, or "purges", the marked-as-deleted data by going
......@@ -39,18 +44,34 @@
* field and instance records.
*
* Purging field data is made somewhat tricky by the fact that, while
* $entity->delete() has a complete entity to pass to the various deletion
* steps, the Field API purge process only has the field data it has previously
* field_attach_delete() has a complete entity to pass to the various deletion
* hooks, the Field API purge process only has the field data it has previously
* stored. It cannot reconstruct complete original entities to pass to the
* deletion operations. It is even possible that the original entity to which
* some Field API data was attached has been itself deleted before the field
* purge operation takes place.
* deletion hooks. It is even possible that the original entity to which some
* Field API data was attached has been itself deleted before the field purge
* operation takes place.
*
* Field API resolves this problem by using stub entities during purge
* operations, containing only the information from the original entity that
* Field API knows about: entity type, ID, revision ID, and bundle. It also
* contains the field data for whichever field instance is currently being
* purged.
* Field API resolves this problem by using "pseudo-entities" during purge
* operations. A pseudo-entity contains only the information from the original
* entity that Field API knows about: entity type, ID, revision ID, and bundle.
* It also contains the field data for whichever field instance is currently
* being purged. For example, suppose that the node type 'story' used to contain
* a field called 'subtitle' but the field was deleted. If node 37 was a story
* with a subtitle, the pseudo-entity passed to the purge hooks would look
* something like this:
*
* @code
* $entity = stdClass Object(
* [nid] => 37,
* [vid] => 37,
* [type] => 'story',
* [subtitle] => array(
* [0] => array(
* 'value' => 'subtitle text',
* ),
* ),
* );
* @endcode
*
* See @link field Field API @endlink for information about the other parts of
* the Field API.
......
......@@ -7,8 +7,13 @@
namespace Drupal\field\Tests;
use Drupal\Core\Language\Language;
/**
* Unit test class for storage-related field behavior.
* Unit test class for storage-related field_attach_* functions.
*
* All field_attach_* test work with all field_storage plugins and
* all hook_field_attach_pre_{load,insert,update}() hooks.
*/
class FieldAttachStorageTest extends FieldUnitTestBase {
......
......@@ -492,10 +492,11 @@ function hook_node_create(\Drupal\Core\Entity\EntityInterface $node) {
*
* This hook is invoked during node loading, which is handled by entity_load(),
* via classes Drupal\node\NodeStorageController and
* Drupal\Core\Entity\DatabaseStorageController. After the node information and
* field values are read from the database or the entity cache,
* hook_entity_load() is invoked on all implementing modules, and finally
* hook_node_load() is invoked on all implementing modules.
* Drupal\Core\Entity\DatabaseStorageController. After the node information is
* read from the database or the entity cache, then field_attach_load_revision()
* or field_attach_load() is called, then hook_entity_load() is invoked on all
* implementing modules, and finally hook_node_load() is invoked on all
* implementing modules.
*
* @param $nodes
* An array of the nodes being loaded, keyed by nid.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment